We've now has 5-10 years of this new batch of FP languages and none of them have 'stuck', they've still not caught on.

It's not cause we're all dummies, it's because, generally speaking, for most problems FP sucks ass.

And that's the obviousness of it. If it were better, it really would have serious traction by now.

Instead people are integrating the best bits of FP into OOP languages. And at that at least they've been a wild success, it's made OOP languages a lot easier to program in. And will make Java easier to program in. Poor old Java programmers. Java 8 will be like a revelation...

You're getting picked on here, and I'm going to do my best to add to the pile. From http://www.johndcook.com/blog/2008/03/25/innovation-ii/ --

""" In 1601, an English sea captain did a controlled experiment to test whether lemon juice could prevent scurvy. He had four ships, three control and one experimental. The experimental group got three teaspoons of lemon juice a day while the control group received none. No one in the experimental group developed scurvy while 110 out of 278 in the control group died of scurvy. Nevertheless, citrus juice was not fully adopted to prevent scurvy until 1865. """

So lemon juice cut the mortality of scurvy in sailors by forty percentage points (!), from 40% to 0% (!!). And a mere 260 years after this was demonstrated, it achieved "traction". Do you think you might be jumping the gun a little here? History would suggest that even if programming in FP style prevented 100% of bugs from occuring, the best you could say about its eventual adoption would be "it's a crapshoot".

I'm going to challenge you right there. First, note that using aspects of functional programming doesn't immediately necessitate you do nothing but functional programming and use nothing but "functional" languages.

Consider a piece of poorly refactored C++ spaghetti you've been tasked with understanding. The same variables mean different things at different times... code assuming vectors have the appropriate length, then later normalizing them in place, and then later yet changing their direction... state being repeatedly accumulated and adjusted in different branches... how do you start cleaning this code up to understand it?

One of the first things in my hat is to start using a more functional style. I sprinkle around the const keyword on local variables like a madman, helping catch all code with side effects to local temporaries. Variables are split in twain, with vectors and their normalized versions being forced to have different labels. But therein lies the advantage: I no longer have to track "x means y except after z when it means y2", but can drastically simplify to "x means y" -- something I can usually encode in the variable name, easing pressure on my feeble memory. Moreover, since the constants stick around, I can paint a better picture of "before and after" much more quickly than through the pinhole of stepping (usually in one direction only) through more procedural code, simply by slapping a breakpoint at the end.

While I'm still not using nor desiring to use functional languages as my bread and butter, integrating functional styles into otherwise procedural code quite frequently helps save my time and sanity outright, even on those occasions when it feels stilted and unnatural compared to the procedural versions.

The biggest reason I have dismissed functional programming languages is that they appear to believe that all problems are pure (which in some cases are entirely appropriate to assume) but then have to exempt themselves from their own paradigms to deal with reality. What I mean is essentially what Kant declares with the categorical imperative, "wish it universal." FP paradigms always seem to have to exempt themselves from this in order to work with a lot of real-world problems.

Of course, I may just be old and not entirely grokking the real abstract ideas of functional programming.

They are obviously not for a substantial subset of the people who started programming with other-than-functional languages, which includes most current programmers. That's not the same as whether or not they are easier to read and write and debug and reason about in general.

> It's not cause we're all dummies, it's because, generally speaking, for most problems FP sucks ass.

Examples?

But seriously, state is inherent in most enterprise apps, which is to say, 95% of apps in existence.

That doesn't justify the claim that for most problems FP is poor; functional languages deal with mutable state, indeed, a big point of FP is that using it provides a way to cleanly divide pieces of code that deal with mutable state so that the presence of mutable state only complicates reasoning about those pieces of code that it inherently must complicate, rather than making the whole code base hard to reason about.