> I've solved production problems with Haskell

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.

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.

I'm not a Haskell expert, and the example may be dated.

Yeah the the very first and by now a worn out dismissal you always see is it's an academic research language, not for writing REAL software.

Out of interest, what kind of software do you build with Haskell? I'm doing web stuff and haven't quite been able to decide whether to stick to Haskell or Elixir for my own projects.

Hm I'd describe it mostly as generic "backend engineering." Web services, databases, data processing, etc. I've used GHCJS as well but I mostly made small changes (I don't have frontend skills.)

In my free time I'm making games in Haskell, but that's slow-going partially due to the ecosystem not being mature but mostly due to lack of free time :)