I've spent a lot of time wrapping my head around monads; whenever I thought I "got it," I would come across some exotic monad that completely blew my mind. The best way to understand them is not to rely on analogies but just follow the rules—everybody says that, but it took me a while to truly realize it.
To explain like two fundamental rules (we can make wrapper types, and do flatmap) I will:
- Write 5 paragraphs setting up an imaginary scenario involving fantasy elements of aliens, dragons, and a magical kindom where they speak using message boxes
- Introduce basic category theory by starting with what a functor is
- Explain all the effects of a monad in such general terms that it basically amounts to anything and everything - since a function can be anything and do everything and it's just function composition
- Write some snippets of Haskell, and just assume that you're familiar with the syntax
I understood the monad concept for a few months in university. After the exam was over, I soon stopped understanding it. The same thing happened with the concept of VC dimension. It's kind of interesting, because we usually don't think of "understanding" as something that comes with a time limit.
It took me a long time to write an explainer on embeddings, and one day I will finally finish my Monad tutorial. I think fundamentally you need to have needed them to solve a problem to get them, and outside of pure languages you have to do a lot of special-condition setup to explain why you need them. "You Could Have Invented Monads"[0] is probably my favourite existing one.
The monad of list is you flatmap a list on a list and instead of getting a list of lists, as you would if you just mapped, you get a single flattened list
The monad of Result is you flatmap many function calls (like http requests or whatever) on each other and instead of getting many results, you get a single flattened result
Most of you already know this, without necessarily even knowing what a Monad is
Monad literally just means "one thing" - you take many things, and flatmap them into one
Honestly, it seems like the common denominator for all this confusion is Haskell, and specifically its IO system, not the monad interface itself. E.g., lots of languages have something like an "Iterable" interface, which - while it may be non-trivial for beginners to learn - absolutely does not require tortured metaphors to explain it. No one has ever needed burritos to explain Result::and_then [1].
21 comments
[ 5.5 ms ] story [ 42.6 ms ] threadPopular well.. submissions in:
2019 (3 points) https://news.ycombinator.com/item?id=19207241
2022 (3 points) https://news.ycombinator.com/item?id=30277518
2024 (11 points) https://news.ycombinator.com/item?id=40332349
I've spent a lot of time wrapping my head around monads; whenever I thought I "got it," I would come across some exotic monad that completely blew my mind. The best way to understand them is not to rely on analogies but just follow the rules—everybody says that, but it took me a while to truly realize it.
See, for example, the Tardis monad or the Cont monad: https://www.reddit.com/r/haskell/comments/446d13/exotic_mona...
When I saw that link it immediately reminded me of this: https://blog.plover.com/prog/burritos.html
>Monads are like burritos
And then a few links down is this link to monad tutorials.
Weird coincidence.
- Write 5 paragraphs setting up an imaginary scenario involving fantasy elements of aliens, dragons, and a magical kindom where they speak using message boxes
- Introduce basic category theory by starting with what a functor is
- Explain all the effects of a monad in such general terms that it basically amounts to anything and everything - since a function can be anything and do everything and it's just function composition
- Write some snippets of Haskell, and just assume that you're familiar with the syntax
- Talk about how delicious burritos are
Monads are just a pattern for chaining functions.
That the best way to understand Monads, was to write a Tutorial about Monads.
Which does make sense. To understand a subject, the best way is to teach the subject.
0: https://blog.sigfpe.com/2006/08/you-could-have-invented-mona...
A monad is anything you can flatmap with
The monad of list is you flatmap a list on a list and instead of getting a list of lists, as you would if you just mapped, you get a single flattened list
The monad of Result is you flatmap many function calls (like http requests or whatever) on each other and instead of getting many results, you get a single flattened result
Most of you already know this, without necessarily even knowing what a Monad is
Monad literally just means "one thing" - you take many things, and flatmap them into one
Thanks for attending my ted talk
[1] https://doc.rust-lang.org/std/result/enum.Result.html#method...
Maybe they could add https://github.com/VincentToups/emacs-utils/blob/master/mona... . I found J.V. Toups writing very nice, and useful to see how monadic composition could exist without type support.