[cageface]

In this interview: http://www.infoq.com/interviews/armstrong-peyton-jones-erlan...

Simon Peyton-Jones, the father of Haskell himself, dismisses the idea that avoiding mutable state automatically buys you easy concurrency:

But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling problems. The overheads overwhelm the benefits,

There are some useful and novel ideas in the FP languages but they're no silver bullet. Whatever the conventional solution for concurrent programming turns out to be, it will have to be exploited in languages more accessible to the median programmer than Haskell.

[loup-vaillant]

Beware: you say "concurrent", but SPJ was talking about "parallel". Not exactly the same.

[cageface]

"Concurrent" is the word he uses repeatedly. What distinction do you make between "parallel" and "concurrent"?

[loup-vaillant]

"Concurrent" is about observable behaviour. Like with a web server, serving many many requests concurrently. When SPJ is talking about concurrency, he is most likely talking about shared state with software transactional memory.

"Parallel" is about optimizing an otherwise linear, or atomic program. Like map-reduce, which can be run on a single CPU or on a distributed cluster. When SPJ is talking about parallelism he is most likely talking about nested data parallelism.

The distinction between the two can be made without ambiguity with the terms "task parallelism" (concurrency), and "data parallelism" (parallelism).

[cageface]

When SPJ is talking about concurrency, he is most likely talking about shared state with software transactional memory.

If you read the interview he is talking about the kind of implicit concurrency FP advocates often suggest you get for free with FP.

I suppose Haskell initially wasn't a concurrent language at all. It was a purely functional language and we had the idea from the beginning that a purely functional language was a good substrate for doing concurrency on. But it turned out to be a lot harder to turn that into reality than I think we really expected because we thought "If you got e1+e2 then you can evaluate e1 at the same time as e2 and everything will be wonderful because they can't affect each other because it's pure."

They had to add things like STM and explicit concurrency management because you don't get this for free just because you're doing FP.

[loup-vaillant]

Oh. He says "concurrent" to talk about data parallelism. (Bayesian update in progress…)