Monads are like burritos (2009)

Original Article ↗ Hacker News Discussion ↗

Programmers revisit the perennial challenge of explaining monads, poking fun at analogies like “monads are like burritos” while arguing that these abstractions are both over-mystified and genuinely hard to teach. Commenters contrast monads’ mathematical roots in category theory with their practical use for things like error handling, async I/O, and sequencing effects in languages such as Haskell, Rust, Scala, and even JavaScript. The exchange broadens into whether functional programming ideas have truly gone mainstream, how much formal math is worth importing into everyday code, and why pedagogy (examples, counterexamples, and good naming) matters more than yet another clever metaphor.

Burritos, jokes, and metaphors

  • Thread starts with burrito/lasagna/endofunctor jokes; “monads are like burritos” framed as an in‑joke among Haskell programmers.
  • Several note that real-world metaphors (burritos, toxic waste, spacesuits, etc.) are mostly shibboleths or clickbait, not real teaching tools.

What is a monad? Practical intuitions

  • Described as:
    • A way to “chain” computations while threading extra context (errors, absence, async, lists, state).
    • “Anything you can flatMap” / “and_then” over, though some argue that over-emphasizing flatMap/chaining causes misconceptions.
    • A wrapper around types plus operations like bind that specify how to sequence them.
  • Common programming examples: Option/Maybe, Result, Future/Promise, IO, lists, streams.
  • Some emphasize monads as one abstraction among many (Functors, Applicatives, Monoids), not inherently special.

Monads, IO, and side effects

  • Haskell IO is explained as building a “to-do list” or blueprint of effects that the runtime executes.
  • IO being a monad is seen as incidental; monads are a convenient way to construct these blueprints while keeping the core language pure.

Teaching monads & the “monad tutorial fallacy”

  • Strong theme: explaining monads abstractly or via metaphors often fails; better to:
    • Teach by many concrete examples and then generalize.
    • Include counterexamples to clarify boundaries.
  • Some argue the real difficulty is higher‑order functions, polymorphism, and typeclasses used together; monads themselves are then “easy.”
  • Suggested resources include challenge-based learning and visual/intuitive introductions.

Usefulness, complexity, and category theory

  • Debate over whether talking about monads as “monoids in the category of endofunctors” helps programmers.
  • Some see category-theoretic language as powerful shared vocabulary; others see it as overkill and gatekeeping, preferring simpler “wrapper/pipeline” descriptions.
  • Concerns that monads and especially monad transformers are practically cumbersome.

Functional programming’s status

  • One view: functional programming “never really caught on” in critical large systems; OOP and Java dominate.
  • Counterpoints:
    • FP ideas (lambdas, higher-order functions, pattern matching, ADTs) are mainstream in many imperative languages.
    • Rust, JavaScript, and frameworks like React embody functional patterns, even if not purely functional.
  • Overall: FP is seen as influential, but pure FP and explicit monad use remain niche.