3 ms·
When jrockway said the burrito thing, I think he was referring to the Brent Yorgey post about the "monad tutorial fallacy": http://byorgey.wordpress.com/2009/0
by Xichekolas 17y ago
When jrockway said the burrito thing, I think he was referring to the Brent Yorgey post about the "monad tutorial fallacy":
http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio...
To summarize: everyone, once they learn Haskell, comes up with their own analogy for "what monads are"... and the analogy, while it makes perfect sense to the person that came up with it, never helps anyone else because everyone gets to monads via a different route.
- eru 17y agoI have the perfect explanation for Monads: Monads are like everything that satisfies the three monad laws. (Of course this only helps mathematicians, if at all. Not mere mortals.)
- jrockway 17y ago"A monad is like a functor, except there is also a 'join' operation."
- eru 17y agoDon't forget about pointed functors in between, i.e. return.
- jrockway 17y agoYeah. My mental picture is "thing with return/pure -> thing with fmap -> thing with join". The second is a pointed functor, the third is monad. Not sure what the first is, probably because it is nearly useless :)
- eru 17y agoYou may have it backward. The mathematicians use "thing with fmap (functor) -> thing with return/pure (pointed functor) -> thing with join (monad)", as far as I know. Arrows are another generalization of Monads that goes in a direction different from functors.
- camccann 17y agoI don't see what even needs explanation. Really, monads are just a monoid object in an endofunctor category. [0] What's the problem? [1] [0] http://ncatlab.org/nlab/show/monoid#examples_6 http://ncatlab.org/nlab/show/monoid#examples_6 [1] http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
- jrockway 17y agoAs I always say, I disagree about this. "Monad" is a property, the "is a" in "is a monad" does not mean the same thing as "is a pencil" or "is an airplane". It means the same thing as "red" does in "red apple" or "red cup" or "red piece of paper". If you look at one of those, and say "red is like an apple", you're just wrong... that's why nobody gets what you're talking about. As soon as you realize that "monad" is a property of types like "red" is a property of things in the physical world, then you have the understanding you need to be able to make "monads" make sense to you. That is all. :)
- Xichekolas 17y agoI'm not sure what I said that you are disagreeing with, but it's not clear to me that "monad" is strictly an adjective like "red". My understanding is that a monad is a data type paired with a properly implemented bind and return (proper in the sense of obeying the monadic laws)... much like a monoid is a tuple with a binary operation and an identity element, a monad is a triple of bind, return, and the data structure. In a practical sense, I find myself saying "this behaves like a monad" rather than "this is a monad" or "this is monadic" (although that last one is an adjective like you say). Once you recognize the that something behaves monadically, you are free to write the plumbing (bind and return) and use the abstraction if you wish. Then again, I'm not a mathematician by any stretch of the imagination, and it's entirely possible I just completely missed the point you were trying to make. Just throwing out my thoughts.
- jrockway 17y agoI think we are saying the same thing. A monad is not a "nuclear waste container" or a "spacesuit". Nuclear waste containers and spacesuits could be monads. But "a implies b" does not mean "b implies a", and that's where people get confused. Anyway, I think what I am trying to say is that the problem is a grammar issue, rather than a programming issue or a mathematical issue. Monads are easy to grasp in terms of math or programming. They are apparently quite difficult to explain, however.
- tel 17y agoA list (for instance) is not a monad. A list plus appropriately defined unit_list and bind_list together form a tuple which is a monad. That's the 'is a' sense of monads. When you refer to a list itself, it's easier to think of it as having the adjective "monaded" since unit and bind are defined even if you don't usually carry them around with you. A list is a monad/has the properties of a monad because the appropriate definitions of unit and bind both can exist and are written.