4 ms·
My advice is not to worry about it (unless the itch bugs you so much that you're willing to invest a lot of time researching the answer). I don't think you'll
by gmfawcett 9y ago
My advice is not to worry about it (unless the itch bugs you so much that you're willing to invest a lot of time researching the answer).
I don't think you'll ever get a single, straight answer that satisfies you. Just reading this discussion, I'm sure you can see that people describe monads in wildly different ways. Some descriptions are minimalist (perhaps a bit reductionist): it's just an algebraic data structure, nothing to get excited about. Many rely heavily on metaphors: containers, "programmable syntax", and yes, even burritos have been used to explain them. Some conflate monads with properties that do show up often in monadic code, but aren't themselves inherently monadic (immutable data, pure functions, sequencing of evaluation). Some are very language-limited, in the sense that the description invariably turns into a debate over the semantic fine-points of the language being used (this will almost always happen when Haskell gets discussed, because expression evaluation is a very subtle thing in Haskell). Frankly it's a mess. The only safe ground you have is the algebraic definition, but that's not terribly useful for building an intuition about how one might use them.
I think that you (and me, and most everyday programmers) would use them in your code only if you were using some library that was designed in a monadic style. In Haskell, so many libraries use monads these days that it's a given: using Haskell for any practical purpose means using monads, whether you want to or not. In Ocaml (about as close to Haskell as you can get without being purely functional), they show up mainly in third-party libraries, mostly when you want to do something tricky like asynchronous I/O -- again, you use monads if you want to use the library. But in run-of-the-mill imperative languages, though, monads don't tend to show up very often, and when they do, they usually are very specific to one library or another.
- chowells 9y agoI like this answer, but it leaves one important thing out. Mathematicians have been studying abstraction for thousands of years. When they decide something is useful, that probably means it has broad applicability and enough functionality to get interesting results out of. Mathematicians decided monads are useful. Take advantage of that. Even if you're working in a language that can't express the abstraction, you can allow it to inform your library design. If something could be a monad, that's usually a better choice than something ad-hoc instead. (Sometimes it's overkill and a monoid would suffice, but both are better choices than an ad-hoc interface without any broadly accepted theoretical basis.)
- gmfawcett 9y agoI'm glad you brought up monoids here as a (sometimes) alternative -- in addition to their inherent properties, people have a much easier time wrapping their heads around monoids. And yes, while abstraction is generally good, principled abstraction is generally better. At the same time, a lousy monadic library is still lousy. The sets of "great libraries" and "algebraically informed libraries" intersect, but neither subsets the other!
- tome 9y agoGreat answer! Should be read by anyone who wants a down-to-earth pre-introduction to monads.