I didn't mean to imply that Haskell was some "perfect language" just that you were wrong to imply that all programming languages are essentially the same. Python, Ruby, Java, and c are all essentially the same, but Haskell, Lisp, Agda are fundamentally different and learning the former groups of languages doesn't really reduce the learning curve in learning the latter.
Yeah that's not really true either. Haskell is functional.
All that means, and all that ever meant, was that the entire language worked around pushing static data into static functions and giving static returns.
I can do that in C, C++, Python, Java and Javascript. The only difference is that it is really the only way I can use Haskell - whereas the other languages are highly flexible, adaptable and actually help me ship product. Most of my APIs work essentially like Haskell - static pre-determined data in, static data out - and the back-end implementation is irrelevant for consumers.
Disclaimer: I'm a newbie in Haskell. I do, however, have experience in Java, Python, Javascript, and even C/C++.
My understanding is that you claim that all these languages can be made to offer you the same benefits as Haskell. I hope I'm not misrepresenting your position, but this is preposterous.
None of these are built around the concept of dumb, immutable data structures and stand-alone function (C/C++ can work with immutable data structures, but most data structures I have seen are mutable). Java is almost completely designed around mutable data structures with associated behaviour (objects), up to the point where you don't have standalone functions.
So, sure, you can have copy constructors everywhere, and static methods (say bye bye to dependency injection...). But it's not idiomatic code. You are fighting against the language and the ecosystem, and the only thing that will likely result is inefficient, bloated code which will get refactored out when it needs to be modified by somebody else than you.
Now, maybe you limit this to your API, but claiming that "the backend implementation is irrelevant for consumers" is a cop-out. Immutable data buys you safety. Maybe you know your code is safe, you don't have any dangling pointer issue anywhere, no concurrency issue, etc. Unfortunately, this might very well not be the case next time you or somebody else refactors your code.
There are certainly reasonable arguments to be made against Haskell (learning curve, Cabal, size of the ecosystem, difficulty of reasoning about performance...). But claiming you get the same benefits in terms of safety out of traditional imperative languages is not one of them. Not to mention higher-level functions, etc, that you certainly are not about to experiment in Java.
