Kevin Hammond (EDT), Greg Michaelson (EDT) Research Directions in Parallel Functional Programming

Annotation

Programming is hard. Building a large program is like constructing a steam locomotive through a hole the size of a postage stamp. An artefact that is the fruit of hundreds of person-years is only ever seen by anyone through a lOO-line window. In some ways it is astonishing that such large systems work at all. But parallel programming is much, much harder. There are so many more things to go wrong. Debugging is a nightmare. A bug that shows up on one run may never happen when you are looking for it - but unfailingly returns as soon as your attention moves elsewhere. A large fraction of the program's code can be made up of marshalling and coordination algorithms. The core application can easily be obscured by a maze of plumbing. Functional programming is a radical, elegant, high-level attack on the programming problem. Radical, because it dramatically eschews side-effects; elegant, because of its close connection with mathematics; high-level, be- cause you can say a lot in one line. But functional programming is definitely not (yet) mainstream. That's the trouble with radical approaches: it's hard for them to break through and become mainstream. But that doesn't make functional programming any less fun, and it has turned out to be a won- derful laboratory for rich type systems, automatic garbage collection, object models, and other stuff that has made the jump into the mainstream.