4 ms·

The first two monad papers, "You could have invented monads" and "Monadic Parsing in Haskell", are terrific. I think that monads and most monad tutorials are g

The first two monad papers, "You could have invented monads" and "Monadic Parsing in Haskell", are terrific. I think that monads and most monad tutorials are great examples of "this concept is hard because everyone says it is." It reminds me of engineering school, where a lot of people sit around and complain about how hard something is instead of actually trying to do that particular thing. Monads really aren't super difficult to grasp, and I wish people would stop making tutorials that only serve to confuse learners more.

platz 13y ago
I think monads may be intimidating at first because it involves an unfamiliar abstraction, and all abstractions take some getting used to. The good news is since they aren't complex, once you understand the abstraction, it appears to be very simple in retrospect. http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio...
- progman 13y ago
  Wikipedia has a pretty good analogy explanation. I like the idea of monads being "programmable semicolons" which are used to inject side effects between purely functional applications. So if I understand monads correctly then they are basically functions that work like a Unix pipe between functions which takes input data in a monadic container, performs some side effects (I/O for instance), and yields another monadic container with output data that is forwarded to the next function - all that without violating the purely functional character of the whole application chain. https://en.wikipedia.org/wiki/Monads_in_functional_programming https://en.wikipedia.org/wiki/Monads_in_functional_programmi...
  - dllthomas 13y ago
    "they are basically functions that work like a Unix pipe between functions which takes input data in a monadic container, performs some side effects (I/O for instance), and yields another monadic container with output data that is forwarded to the next function - all that without violating the purely functional character of the whole application chain." That much is true of any applicative functor (which is a superset of monads). The additional power monad gives you is to change up the later portions of that chain based on the earlier results. Of course, a lot of uses of "monads" don't really make the distinction (and applicative functors are plenty useful).
  - freyrs3 13y ago
    > performs some side effects (I/O for instance), What you're describing is the IO monad to first approximation, most monads don't perform side-effects at all ( List, Cont, Maybe, ... ) and the bind operations only performs some pure overloaded operation specific to the monad instance. For example the list monad performs the concatMap function which is pure. instance Monad [] where m >>= f = concat (map f m) return x = [x]
- DalekBaldwin 13y ago
  I'd say it is in fact a familiar abstraction (as the "You Could Have Invented Monads" article shows) that's presented in an unfamiliar way with unfamiliar syntax. Taking something you already understand intuitively and learning to express it in a new formal framework (like much of Haskell) is often harder than learning something brand new in a formal model and slowly developing an intuition for it (like much of physics). Sometimes gaining a formal understanding enriches your intuition and vice versa, but I haven't experienced anything like that with Haskell so far.
thinkpad20 13y ago
There are a lot of concepts that need to be learned first before monads become simple; namely, functional programming (in general, including the lambda calculus, currying and function composition), and Haskell's type system and how type classes work. All of this stuff needs to be understood at a fairly intuitive level. Add to this that the way much monadic code is often used, and the `do` syntax that supports it, can mislead newcomers into trying to understand monadic code as similar to imperative code. Add also that many of the most common monads, like the State monad, have clever monadic instances involving passing functions around which are beautiful but hardly intuitive to understand. Add further that many monads used in practice are monad transformers, increasing the complexity and opacity further and making production code hard to grok for beginners. So there are many legitimate reasons why monads are a hard concept. That said, I completely agree that the best way to learn them is to actually try to use them. In fact, I think that the main reason monad tutorials are seen as useless is not because they're poorly written, but because no tutorial can teach you monads a fraction as well as you will learn them by actually using them.

platz 13y ago

I think monads may be intimidating at first because it involves an unfamiliar abstraction, and all abstractions take some getting used to. The good news is since they aren't complex, once you understand the abstraction, it appears to be very simple in retrospect. http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio...

progman 13y ago
Wikipedia has a pretty good analogy explanation. I like the idea of monads being "programmable semicolons" which are used to inject side effects between purely functional applications. So if I understand monads correctly then they are basically functions that work like a Unix pipe between functions which takes input data in a monadic container, performs some side effects (I/O for instance), and yields another monadic container with output data that is forwarded to the next function - all that without violating the purely functional character of the whole application chain. https://en.wikipedia.org/wiki/Monads_in_functional_programming https://en.wikipedia.org/wiki/Monads_in_functional_programmi...
- dllthomas 13y ago
  "they are basically functions that work like a Unix pipe between functions which takes input data in a monadic container, performs some side effects (I/O for instance), and yields another monadic container with output data that is forwarded to the next function - all that without violating the purely functional character of the whole application chain." That much is true of any applicative functor (which is a superset of monads). The additional power monad gives you is to change up the later portions of that chain based on the earlier results. Of course, a lot of uses of "monads" don't really make the distinction (and applicative functors are plenty useful).
- freyrs3 13y ago
  > performs some side effects (I/O for instance), What you're describing is the IO monad to first approximation, most monads don't perform side-effects at all ( List, Cont, Maybe, ... ) and the bind operations only performs some pure overloaded operation specific to the monad instance. For example the list monad performs the concatMap function which is pure. instance Monad [] where m >>= f = concat (map f m) return x = [x]
DalekBaldwin 13y ago
I'd say it is in fact a familiar abstraction (as the "You Could Have Invented Monads" article shows) that's presented in an unfamiliar way with unfamiliar syntax. Taking something you already understand intuitively and learning to express it in a new formal framework (like much of Haskell) is often harder than learning something brand new in a formal model and slowly developing an intuition for it (like much of physics). Sometimes gaining a formal understanding enriches your intuition and vice versa, but I haven't experienced anything like that with Haskell so far.

thinkpad20 13y ago

There are a lot of concepts that need to be learned first before monads become simple; namely, functional programming (in general, including the lambda calculus, currying and function composition), and Haskell's type system and how type classes work. All of this stuff needs to be understood at a fairly intuitive level. Add to this that the way much monadic code is often used, and the `do` syntax that supports it, can mislead newcomers into trying to understand monadic code as similar to imperative code. Add also that many of the most common monads, like the State monad, have clever monadic instances involving passing functions around which are beautiful but hardly intuitive to understand. Add further that many monads used in practice are monad transformers, increasing the complexity and opacity further and making production code hard to grok for beginners. So there are many legitimate reasons why monads are a hard concept. That said, I completely agree that the best way to learn them is to actually try to use them. In fact, I think that the main reason monad tutorials are seen as useless is not because they're poorly written, but because no tutorial can teach you monads a fraction as well as you will learn them by actually using them.