I agree, so it's a good thing he didn't make that claim ;-)

Lots of languages are incorporating functional features, from dynamic languages like Python to even Java's support for closures. To really get your head around these features, it pays to play with a real functional language for a bit.

You can be a good bricklayer without knowing much about structural engineering. What happens when you want to build something taller than ten stories?

What happens when you want to program for more than ten CPU cores?

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.

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.

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.

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.

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!"

Learning functional programming for a programmer is like learning programming for a non-programmer. Someone who is a logistics expert is valuable. A logistics expert who knows how to program is even more so.

OO programmers who understand functional programming have a big advantage over OO programmers who don't. Learning FP gives one the mental tools to do better encapsulation.

I have written code for hundreds of cores. (can you say CUDA?) It was written entirely in C and ran very fast.

Thats great, but anecdotal evidence doesn't really prove anything. CUDA lets you write multi-core code for GPUs, but imagine writing C code for hundreds of cores over a datacenter cluster. C isn't the right tool for that job.