Which Haskell design decision flies in the face of production use or what kind of feature would you like you to see in Haskell that isn't picked up due to it being an academic language?
I’ve not used Haskell (so I have no idea of the validity) but the criticism I always hear leveled in discussions is that lazy evaluation makes runtime hard to reason about.
Haskell involves significant unlearning of imperative approaches.
99 bottles of beer with state monads gets at some of the challenge for the neophyte:
http://www.99-bottles-of-beer.net/language-haskell-1360.html
Look at the struggle going on to deal with a "simple" piece of state.
That's not a particularly great example though because 99 bottles of beer is not a particularly stateful computation. You could easily do it without state at all like this: https://gist.github.com/lgastako/2e7dfd6b1118bb408ff114a4be4...
On the other hand this blog post http://www.haskellforall.com/2013/05/program-imperatively-us... demonstrates how one of the bits of Haskell that some people find complex (lenses) can be used together with the state monad to provide an "imperative-like" experience that's even nicer than most imperative languages.
There were other examples, but figuring out how to deal with state is the most arcane and mystical aspect of haskell.
Is it just me, or is the linked example messed up in all sorts of ways, even ignoring the use of monads and transformers? Looks like a novice trying to code in fancy ways.
For instance, it defines a Beer datatype, yet stores a plain Int in the state, then casts it to Beer only to use a custom pretty printer, instead of creating a verse :: Int -> String, or verse :: Beer -> String function.
What I said was that Haskell's design and evolution have been primarily guided by research questions rather than business needs, not that it's unsuitable for production use. I didn't say it's unsuitable for production use, nor do I think it. That doesn't change the pretty obvious fact that its features are mostly guided by research questions.
> barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%)
If that effect were scalable and largely universal, then there would be no need for this discussion, anyway. But if it works well for you and the other thousands of developers who make up ~0.06% of the market, then it's great that it's available. Research languages also serve a very valuable goal in figuring out what works and what doesn't. If no one used them, we wouldn't know.