Hmm ... Pedagogically, I wonder if Haskell suffers from this emphasis on math. For instance, I couldn't figure out State monad for the life of me, and in gener

Hmm ... Pedagogically, I wonder if Haskell suffers from this emphasis on math. For instance, I couldn't figure out State monad for the life of me, and in general how monadic calls could maintain a context "in the background". Explanations like "it's easy just follow the Kleisli arrows" weren't helping. Finally I did the exercise of manually "inlining" every >>=, 'get' and 'modify' call in a trivial example of a StateT function calling another StateT function. And then I got it. Truckloads of closures/continuations, constant calls to re-create the monad with new information. Function calls with functions as arguments that close over the previous calling function's state. A lot of this was specific to how StateT + Identity unwrapped; I'm sure inlining other monads would reveal different things, and unwrapping IO is impossible in GHC :). My point is, math has been a great source of Haskell's incredible expressivity, but the pedagogical focus on math threatens to mask it's greatest triumph in Haskell: making all of that boilerplate code go away with incredible precision and elegance. When you rip it open and see what >>= or 'do ... get ... modify' is doing, you feel the power. I feel like the article suggests this, too: The only thing you need category theory for is to take great categorical and mathematical concepts from the world and import them back to programming, and translate them along the way so that others don’t need to make the same journey you did. At least for advanced programmers from other worlds, they need to see the guts to appreciate how amazing this stuff is.