One point might be, that Haskell thinks big. Its strengths might not be too noticeable with smaller projects and be problematic because of a steeper learning cu

One point might be, that Haskell thinks big. Its strengths might not be too noticeable with smaller projects and be problematic because of a steeper learning curve. The inertia is huge. Imperative programming has a lot of momentum, because it reads more or less like text, not maths. A steep learning curve means effectively more power. And that means responsibility. If modularization means separation of concerns, and thus less responsibility, lack of power is largely mitigated, but it puts the responsibility on the s/w-architects. Just like LISP's strength supposedly is revealed when it's the whole OS. And as they say, any involved program will contain an ad-hoc implementation of LISP :) C, eg., also resembled the hardware architecture more closely. With concurrent programming, though, we see more functional influences creep into the staple languages. It's the other way around with Haskell's do notation. Anyway, as a research project, it is rather academic. Therefore it is often not backwards compatible, which is an immediate show stopper and also shows that it's far from finished, due to its bigger goals.