Additionally, one of the more important criticisms that I actually shared with the OP is that it took me a few evenings to get up and running with Haskell around 2008-2009 on Mac OS X. However that problem has been just about completely solved by the Haskell platform (http://hackage.haskell.org/platform/) these days.

Also, recent activity in the Snap and Yesod web frameworks makes me more optimistic for Haskell adoption in industry, although it still has to clear a lot of adoption hurdles before it becomes more common.

My theory is that Haskell has a lot of usability problems. A programming language is a UI for programmers. Usability issues are always a sufficient explanation for market disappointments in any product or field.

Most notably, Haskell is rooted in a theoretical foundation that's essentially a major subfield of 20th-century mathematics, using concepts and notations which most programmers (a) do not understand, (b) do not want to understand, (c) do not need to understand, and (d) in many cases are not physically capable of understanding (eg, they have IQs < 140, or other sorts of subtle congenital damage to the math lobes).

As "LYAH" demonstrates, it's possible to teach programmers (or at least a certain subset thereof) to use Haskell without fully understanding it. But this approach has serious UI problems of its own. It's not very comfortable to use a platform whose semantics you don't understand. There's no comparable hidden complexity in Ruby, Python, Perl, JS, etc.

Laziness is also a significant UI problem, inasmuch as it becomes cognitively very difficult to understand and/or control the performance of your program. Typically in UI, when you find one UI disaster you find more - it shows that usability was not a principal goal of the project.

One of the difficulties in diagnosing usability problems of this type is that people rarely complain about them directly, because their complaint would typically be of the form "Haskell made me feel stupid." My guess is that for everyone who's succeeded in learning them a Haskell, there are four or five who tried it and came away feeling stupid. Not a very pleasant sensation.

I could not care less. The post is well-written, and makes a case. You can criticize his case, or even the facts he mentions or you could ignore them, but calling him a troll is totally unproductive (essentially it means: "his arguments are BS because he is a bad person, but I won't say what's specifically bad about them").

I also find that (to keep with Sturgeon's Law perhaps) 90% of uses of the accusation "troll" are misuses, mostly translating too "the guy makes arguments we don't like, and he won't go away".

Also, to everyone: he doesn't say that installing Haskell takes too days. He says it took 2 days to HIM --and AT THE TIME. Perhaps he wasn't using the all-too-might distribution you are using where it's one apt-get away...

Really? This implies you have some knowledge of what would have happen if C/C-descendants did not exist.

It also implies that C/C-desc adoption was a historical accident, or an idiotic move, instead of something based on very pragmatic decisions. To write a performant program until at least 1990, from a word processor to a game, you needed not only C-level speed but also lots of tricks and twists to your code (ingenuity), most of which were only possible because of the low-level access C provides and the programmer's knowledge of the program's state (so a higher level compiler couldn't easily derive and do the same optimizations for generic programs). And sometimes you even have to drop in assembly. Remember all those 80's games (like Prince of Persia) written in assembly?

So, even if C didn't exist, it would have to be invented (or something much like it). Worse case scenario, we would be using assembly.

After the 90's, with 486's etc, the situation got better, in the sense that we could even afford garbage collection. Still, our expectations got bigger too. Whereas 256 graphics and SID sound on a largely uni-tasking system was good for the eighties (at best you have some expensive Unix workstation and you run X with 4-5 programs loaded, X-eyes included), we now want millions of color, multiple CD-quality sound streams playing, 10-20 heavy programs loaded at once, GPU compositors, streaming audio and video, anti-aliased fonts, etc etc.

So, still, a high level solution feels slow compared to C/C++ when it does today's state of the art (for 10-years ago or yesterday's state of the art, even Python or Javascript is sufficient). Same for UIs (where waiting for the user's actions is the largest slowdown).

As long as you get into the "cpu intensive" or "memory bound" issue, anything but C/C++ seems slow.

(C descendant's like Java/C#/Go etc are also slow --not arguing that. Any multimedia app done in Java, for example, is like a relic from the 90's).

Haskell's operators are wonk:

[0,1,2,3]!!2

versus:

[0,1,2,3][2]

Clearly !! is a logical array indexing operator.

You've never read a Lisp thread with non-Lispers, have you? :-) The amount of whining about parentheses is incredible.