I believe the reason is easiest to understand if you code in an impure language but in an almost entirely purely functional style. This limits mutation to comparatively tiny parts of the code base and massively reduces the number of mutexes required to add parallelism safely.

For example, our visualization software used to be written in (highly imperative) C++ and, consequently, was practically impossible to parallelize. However, switching to OCaml (an impure functional programming language) made it easy to rewrite the software more concisely, more efficiently and with only a tiny amount of mutation (in performance-critical parts). Consequently, parallelizing the OCaml code required only 4 mutexes in 250kLOC of code!

So purely functional programming helps because it makes the number of locks in your code scale up very slowly with the size of the code base itself.

However, if you’re asking how/if the elimination of all mutation and the replacement of locks with other concurrency constructs solves the parallelism problem, I agree. I have seen a lot of evidence to suggest that it helps with (even cures) massive concurrency but never in the context of parallel programming.

The Haskell community keep making such claims and I keep responding by asking them to parallelize some of the example programs from my books but all I’ve ever seen is Fibonacci number generators and other such programs that have absolutely no bearing on real parallel programming.

Haskell does have some interesting work in progress on data parallelism (http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell), but I’m sure they’re a long way away from any form of proof yet.

Joseph K: Not sure what you mean by “you academics”, and no, I didn’t say that we shouldn’t pay attention to Erlang/Haskell/whatever — I said we should try to find out if the claims being made for them are true or not. If they are, that’s interesting; if they’re not, that’s interesting too.

Thomas L: have you included testimonials from people who tried Erlang and gave up in your sample? If not, perhaps “totally biased” cuts both ways

See also http://pyre.third-bit.com/blog/archives/1271.html.

I can understand your issue with the obvious hyperbole in Nat’s statement, but I think it is short-sighted to disregard the testimonial of the hundreds of people that have recently moved their applications to Erlang. They all state the same thing: it is much easier to produce a reliable, maintainable application in Erlang than with other parallel frameworks.

So, how are the book sales going? Sorry, I’ve already blown my budget for the holidays, so I won’t be able to order a copy.