>It's not obvious and also fragile (maybe the sort changes at some point its constant or even asymptotic behaviour?)

Tome pointed out that "sort" in haskell is a merge sort, but I have to say I strongly disagree with this point. I was a hardcore C++ proponent for a long time and the reason for that was the STL. What made the STL great, for me, was that the performance was effectively part of the spec of the container types.

So it's true, if you wanted to implement "max" as I did in my example you couldn't use a sort that was simply "sort as efficiently as possible" or some such. You would need a function known to be "mergeSort" or similar. I don't view this as fragile, it's higher level programming: building upon blocks with known correct behavior. It is not trivial either, but I'm not sure engineering can be.

>Well, I'm sorry for turning this into almost an emotional issue.

If you're arguing in good faith, then all is well. There are just a hand full of trolls out there that have to go out and trash haskell where ever they see it mentioned, so if the conversation develops that kind of feel I tend to back out.

>I have seen way too many advocating that makes it seem like this vague idea of "safety by type-safety" is the only issue that comes up in software development.

For me, the reason I switched to Haskell was simply time: I need as much help from the system as I can get. The more the system can find bugs for me the better. But, of course, this only works if you go "all in". You need to make an effort to push as much information as you can into the type system where the compiler can help you (I find this part similar to how I programmed C++). You need to make an effort to make invalid programs impossible to compile. If one doesn't do these things then they probably won't get enough out of the language to make it worth it.

>It doesn't help all that much for correctness, and other aspects like modularity, efficiency, portability, compiling speed, development speed etc. are at least equally important for the vast majority of projects.

For correctness, it depends very much on how successful one is in encoding their program into the type system.

I find modularity to be good but tends to be a community problem more than a language problem: for what ever bizarre reason, Haskell programers tend to not like imports and/or dependancies. Amusingly, one of the most popular packages in Haskell (Lens) mostly ignores these convensions.

Efficiency can be done but it's effort. I find Haskell quite good here: you can do the simpliest thing and it will often be good or correct. If benchmarking tells you that it's too slow then you have a lot of opportunity to make things a lot more efficient without losing all of the elegance.

Portability, I find also good. Not the most portable language that exists but workable.

Compiling speed... I don't see Haskell ever competing with languages like e.g. Go on compile speed. Ocaml is pretty fast though. :)

Development speed, IMO, depends on having a good IDE. Some members are working on this but Haskell doesn't have the community of more popular languages to get this one completed and polished. I would expect Haskell development with an IDE on the level of Visual Studio+Resharper to be the fastest of typed languages because e.g. refactoring would have so much better information to work with (assuming proper use of the type system).

>It is no coincidence that most Haskell projects never take off.

Well, I doubt that is a coincidence but I suspect there are a lot of reasons. Haskell doesn't have the popularity of e.g. Java so it won't have the amount of libraries, the robustness, etc. For me, Java is a classic example of what community focus can do: the language is trivial. It's not powerful at all, all it has are classes, functions and interfaces basically, yet so many people have been working with it for so long it has libraries and software for most anything one can think to do with it. There are tools to deal with its horrible verbosity, etc.

For me, I have no expectation of Haskell to compete directly with Java. My only expection is that Haskell would get to a state at least as good as Java with a lot smaller community (though, obviously, larger than it currently has).

>they focus way too much on some perceived gains from very advanced type system tricks, but they are basically too hard to use in a practical setting.

I'm not sure on this. The type system for e.g. Servant is so good you can impliment trivial servers basically with the types alone. Of course, the critical question is: is this the place most people are having difficulty in web development? If it's not then this effort, cool as it is, will obviously have a limited effect on anything.

>When I look at the open projects page at toptal.com I can see exactly one Haskell project,...

Is this not likely to be the consequence of community size? Community size probably has some relation to language but, for me, it's hard to nail down. Haskell works different than other languages so that, on its own, will exclude a lot of people no matter how good it is. Java took C++'s well known syntax and get rid of anything remotely difficult to use, so that's easy for popularity.

>Even most Haskellers don't disagree that it's mostly good for expanding your mind, exploring mathematical ideas etc.

This could be, I don't know what most Haskellers want with it. I know there are companies that use it in production and I use it as a productive language.