It's much harder (in my experience) for very smart people to write decent code in C, C++, Python etc than in Haskell, simply because so much of their smartness is consumed by having to constantly think about what code might break their program.

Haskell, it seems, while using the same slogans, plus FP and lazyness buzzwords, is really doing the job when you follow its conventions.

Actually, that part which re-implements standard FP techniques with very clever and concise, based on familiar conventions (currying, laziness) syntax, along with ability to write "curried type signatures" is remarkable. It feels much better than SML.

It is definitely the language worth of learning after Scheme/CL.)

The fact that corporate overlords selling Java made certain overhyped promises does not have any bearing whatsoever on the merits of Haskell.

Let's break it down: Java fixed memory management at a significant performance cost, but they didn't solve null references, and in practice it was a big enough of an advancement to actually get a foothold against C++.

Haskell on the other hand actually solves null references as well, so the bugspace that it actually eliminates is easily an order of magnitude bigger than Java's, and it does so without being particularly slow or verbose.

Now as to the rest of your argument, of course it's true that FP principles can be applied anywhere, and given the correct discipline you can achieve much of the same benefits through careful architecture and coding practices. However what you're dismissing is the value of the compiler guarantee, and that should not be minimized. Of course we can look at any code sample and reason about how it should be structured to minimize side effects. But the problems with mutability and null references are endemic to large systems, not isolated features. Where Haskell's guarantees start to shine is when your code base goes over 100kloc and no one person understands the whole thing anymore and the preconditions informing the design no longer apply and things have been hacked from a dozen different perspectives. In this case those guarantees have non-trivial value.

Yes, there are trade-offs in terms of programmer convenience, which is why type-inference research exists.

However, getting bug reports from a static analyzer that runs before your code goes into production and proves strong, complex theorems about your code before allowing it into production will always beat having to manually write extensive test suites.

In fact, speaking of test suites, I recommend checking out Haskell's quickcheck library, and the Scala equivalent whose name I forget at the moment. They use the type system to help automatically generate better test suites, for those properties of your code you cannot yet prove correct.

That's because that cost isn't actually necessary, it's just Haskell being Haskell. There are plenty of other languages with different type systems that allow for heterogeneous lists very easily (for example, Scala will let you write List[Any] and it will type-check). And some of us research guys are trying to make advances in this stuff (I actually have to email someone to talk about a paper somewhat related to this).

Neither of these is true. Both heterogeneous lists and tuples (indeed any data structure) are possible in Haskell; all thanks to algebraic data types.

It could very well be that most programmers just don't like programming that way, and thus Haskell sucks.

Frankly, from my experience with dynamically typed languages such as Clojure few people actually make heterogeneous lists and vectors beyond a handful of elements; a use case which is covered nicely by Haskell's tuples. Long hetereogeneous lists and vectors are not particularly useful because they cannot be reduced/folded -- unless your reducing function accounts for all the different types but then why not use an algebraic data type with pattern matching?

Of course, there is TYPECASE in CL and some similar macro in Clojure, but Haskell's pattern-matching syntax is more concise.