I tried Haskell for 5 years

Ha, I guess this must be some kind of selective blindness then :) I've seen myThreadId many times, it makes perfect sense, and yet, whenever I've had to grab the spawned thread id I've always reached for mfix... Well, in this particular case there's of course no need for that.

But the general pattern applies to many things. One other example that immediately springs to mind is e.g. registering a callback while needing the ability to unregister the callback from within itself, using some sort of id returned from the registering function.

haskell is objectively expressive. (where expressive means amount of logic per character)

there are multiple reasons for this, kind've tied together. Whitespace is function application (no parenthesis to keep track of like lisp, or even e.g. c, java, or javascript, when programming in a functional style). Immutability forces you to compartmentalize and compose everything. when everything is a function, function and variable names serve as VERY powerful documentation, especially when combined with haskell's also VERY powerful type system (which e.g. has sum types where most languages do not, which allows for example, defining most error states of program as a data type (which can then derive from any typeclass)).

one of the primary benefits of laziness is to make function composition possible under a wider variety of situations (which also increases expressiveness, at the cost of occasional though not difficult to avoid space leaks)

one joke I've heard is that the ideal haskell program is 20 lines of imports and one line of perl.

> you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system

That is dangerously close to the infamous "if it compiles, then it works" boast, which Haskellers make all the time (while denying that they make it), demonstrating in the process that they don't write real software, where the defects one encounters are very often of a nature such that the program behaves exactly as intended by its authors, but the intended behavior is itself wrong. How does the type system help here?

My comment wasn't glib. I actually think those phenomena quite well explain much Haskell advocacy. Considering how massive an undertaking it is to learn the language and its Byzantinely-complex, PhD-theses-in-disguise libraries (each of which sports a zoo of custom operators) and how small the payoff is, it's unsurprising that those who take the plunge begin zealously encouraging others to do the same, lest their own investment have been for nothing. In a way it's like a conspiracy.

Haskell is good for problems where you want to spend most of your time thinking in terms of the problem domain and not so much about all the little implementation details.

For instance, if you were to write a CAD program, you probable want to be spending your time thinking about algebra and geometry, and not about little details like how an array is laid out in memory or when memory needs to be freed. The latter might be important for optimizing the last bit of performance out of a tight loop, but a lot of problems are hard enough on their own that just coming up with any solution that works is enough trouble on its own.

It's also good for problems where you want pretty good performance but don't have to be as fast as C, or where you want to take advantage of multi-core parallelism but don't want to deal with the usual complexities of threaded code.

Persistent data structures are really nice for certain kinds of applications, such as web services, where you have some complex internal state that needs to be updated periodically. Error handling is really easy when you can just bail out when something fails, since none of the state was ever modified-in-place and your old pointer to the old state is still valid.

The powerful static type checker makes Haskell a good fit for applications where it's really important that you calculate the right answer, or where you don't want to spend much time tracking down weird bugs.

Haskell isn't so good at applications where you need hard real-time guarantees or you want to have very fine control over the memory layout of your data structures or you want to be able to easily predict CPU or memory usage.

I am not holding that (joke's) view, but monad came to mind as an ongoing academic research (to original Haskell at least) in order to solve a rather trivial stateful programming (trivial in an imperative style). To generalize that example, there are solutions that are trivial to express in an imperative style but seems convoluted in pure functional programming. How to retain the trivialness are subject of ongoing academic research.

EDIT: To be specific, I can think about the example of machine efficiency that can simply be specified literally in C but it is uncertain and opaque in Haskell.