[joegaudet]

I find the assertion that the ONLY way to program for multiple cores or concurrency is to use functional programming annoying. It seems to be the default fall back of functional evangelists, as if there were no other way in the world to solve concurrency.

I recently took a course on concurrent programming, and the from what I learned, some problems are easier to deal with in erlang or something similar. But then again some aren't. And a lot of the time, they run an order of magnitude slower (though as my prof would say, correctness is sometimes more valuable than speed).

And granted my Erlang program for matrix multiplication was very concise. My MPI implementation ran WAY faster.

It seems to me, there are two schools of thought, and you can live in one, the other, or both. Certainly there are things to be learned in either.

I think all one can take away from articles like this is that it's good to keep learning.

[chc]

You seem to be confusing "Erlang" with "functional programming." They are not equivalent. Erlang is not what makes functional style good for concurrency — it takes advantage of some of the factors, but it is not the be-all-end-all. Erlang's actor-based green-threaded messaging is only one concurrency style.

[joegaudet]

I was using Erlang as an example as I am familiar with it. My point was more so that there are (as you say) many styles of concurrency, and that I hate it when functional programers use "Try programming concurrently in an imperative language" as their fall back argument for the merits of FP.

[Dunearhp]

It is one of the few arguments that doesn't first require the other person to have a deep understanding of functional programming.

Try to convince someone of the value of immutability without mentioning concurrency.

Imperative and functional programming relate in the same way that arithmetic and algebra relate. It is hard to do deep reasoning in maths without algebra and it is impossible to evaluate the value of most algebraic expressions without arithmetic.

There is a reason that functional programming is at the forefront of concurrency research. In the long run, imperative only approaches will be unable to compete, and functional only approaches will remain on paper.

[chc]

That's because support for concurrency is one of the most relevant strengths of functional programming. It's a buzzword right now, and a lot of the advice for how to do it well points toward functional programming practices, so they see that and say, "Hey, we should let people know that we already have all this stuff!"