1. 16
  1.  

  2. 10

    (Copied from my HN comment, but suitably general for this audience as well:)

    The elided punchline is that this entire essay is “just the Either monad”.

    If you can forgive the snark there, the point to take home is that this entire pattern of programming can be nicely summarized through some very high-order topics like Monads. That’s one “why” for “why should I learn what ‘monad’ means”. A very similar essay could be written for non-deterministic programming (“it’s ‘just’ the List or Logic monad”), for backtracking parser combinators (“they’re ‘just’ the State + List monad”), or for state threads themselves (“they’re ‘just’ the State monad”). Each of these programming patterns is neatly summarized by the “obvious” behaviors of a simple type.

    One of the powers of Haskell is that it lets you abstract over patterns like this and talk about them inside your language. That’s why Haskell has such a fetish with Monads—it’s as though GoF had been formally encoded into the language. This notion comes up a lot under the name “Monad” but it might also be “Profunctor” or “Applicative” or “Category”.

    I really love this essay because it really goes through all the details. Oftentimes an advanced Haskell/ML/F# programmer might summarize a large topic as “it’s just the X monad” anticipating that someone familiar with this kind of programming can reverse engineer almost all of the meaning from that plain statement. This is typically true, but certainly expects a lot of experience from the listener.

    This essay unpacks all of that meaning and presents it in easily digestible bits. That’s great technical writing.