This brings to mind what I consider to be perhaps the biggest issue with Haskell (I'm not accusing you of this, you've done a great job explaining): due to language expressiveness, overly generic code is far too often a baseline, when it really shouldn't be.
The language itself doesn't demand we write code this way, but the community, understandably, loves to be as expressive as possible in many cases.
But all of this comes with a cost of cognitive overhead that seems to rarely be worth paying.
Elm was an enlightening experience for me, having started with Haskell, because it helped me to realize just how little I ever took advantage of a lot of the very generic Haskell code, and how far the simplest of functions and types could take you in the overwhelming majority of cases.
The language itself doesn't demand we write code this way, but the community, understandably, loves to be as expressive as possible in many cases.
But all of this comes with a cost of cognitive overhead that seems to rarely be worth paying.
Elm was an enlightening experience for me, having started with Haskell, because it helped me to realize just how little I ever took advantage of a lot of the very generic Haskell code, and how far the simplest of functions and types could take you in the overwhelming majority of cases.