Abstraction, intuition, and the “monad tutorial fallacy” (2009)
This is a good post.<p>I know the point is broader than monads specifically, but I have to admit I think “explaining monads” have probably done more harm to understanding monads than anything to do with monads themselves. [Proceeds to commit the same error discussed in the post.]<p>In my experience, the best way to explain monads to someone who isn’t approaching them from a theoretical perspective is to relate them to abstractions they already understand—whether they’re actually monads or close enough if you squint.<p>I got there by relating the concept to jQuery. A lot of JS devs get there by relating it to Promises. (Aside: I had a minor revelatory moment when I realized the old Node-style `(error, result) =&gt; {…}` callbacks were essentially a Maybe&#x2F;Option type in different syntax.)<p>It’s not a far reach, for learners with that familiarity, to go along for the next step where you can apply the same semantics to anything in a similarly wrapped structure.<p>That’s not “think of it as a burrito”, unless that example particularly resonates with the audience. It’s: once you have the aha moment, your teaching effectiveness depends on being able to recognize the pattern in your audience’s domain.<p>Which I guess is restating the post’s point, but I think it’s good to demystify monads in particular.