Are they? I'd argue most real-world Haskell code doesn't abstract enough, perhaps out of over-reaction to this untrue assertion that seems prevalent these days.
> This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.
A lack of that isn't the fault of re-using powerful abstractions at the base, it's a failure of not making the concrete implementations more obvious.
It would be most constructive if we could work with examples, but I don't know what the origional commenter had in mind since that hasn't been my experience with industrial Haskell.
> Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means.
Why all the conversation about category theory? I've read most of Algebra Drive Design and I think you've mentioned it more times than the book!
> Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list".
You can write your TODO list in Haskell without thinking about Arrows for sure, and very likely without thinking about Monads.