The only way you will see FP doing massive parallelism at speeds even close to current best is if they wrap the C MPI interface, and I have yet to see any funct

The only way you will see FP doing massive parallelism at speeds even close to current best is if they wrap the C MPI interface, and I have yet to see any functional message-passing APIs which aren't tarted-up imperative environments True, I would not be surprised if it evolved that way, but according to my (modest) knowlegde, it is possible for imperative routines to have a purely functional interface. The extreme case of course is the fact that any functional high-level code needs to be translated to assembly code to run at all, but I don't see why that boundary can't be on a higher level; As long as the developer programs functionally (and derives the benefits from that), does it matter that his code is being translated first into imperative MPI-ified C, and then assembly? This is all provided, of course, that you can actually leverage the parallelism-related benefits of FP this way, which I guess is not known as of yet. You mentioned "functional message-passing APIs which [are] tarted-up imperative environments", care to give an example? I'm intrigued... As for MapReduce, of course it's different from what the average HPC machine is used for, but being an embarrassingly parallel problem, it's one of the first problems where the FP approach has been shown to work. In other (eg typical HPC) applications, there's lots of work ahead in rethinking the algorithms so they can be expressed functionally, before you can even begin contemplating how to use the hardware.