4 ms·
The best explanation I've read about monads was actually in a blog, written in Python. When you jettison the burrito analogies, category theory and all that stu
by blippage 5y ago
The best explanation I've read about monads was actually in a blog, written in Python. When you jettison the burrito analogies, category theory and all that stuff, it's actually not all that bad.
I can't find the page, unfortunately.
In essence, think of a monad as something that takes a callback function. The callback function returns something. The monad calls the callback, and then does something based on the result. Once you get that into your head, it becomes a lot easier to understand what's going on.
- bradrn 5y agoYes! This is exactly how I prefer to explain monads to non-Haskellers. A monad is just a unified abstraction for a certain type of callback which pops up in a bunch of different places (promises, optionals, randomness etc.). In some ways, it’s almost like a formalised version of an design pattern in the OOP sense. There’s really no need for category theory or strained analogies to understand or use monads in normal Haskell code. (Of course, the theoretical underpinnings are still very interesting in and of themselves! They’re also a source for new patterns — things like free monads and comonads are very, very useful indeed. But it’s entirely possible to program Haskell without knowing a thing about category theory; most Haskellers don’t.)