3 ms·

I think it's kind of amusing that right after sternly warning the reader to avoid monad tutorials, he then proceeds to write a monad tutorial. I guess you just

I think it's kind of amusing that right after sternly warning the reader to avoid monad tutorials, he then proceeds to write a monad tutorial. I guess you just can't resist...

gamegoblin 13y ago
After I finally understood monads I thought about writing a tutorial. My thought process was "Well I understand it now, why couldn't someone have just explained it this way". Then I reevaluated and realized everyone has those thoughts. It's just a hard concept to grasp on the first try. One really just has to grind away and force themselves to use monads for a long enough time to really grok them.
- username223 13y ago
  I wouldn't call monads "hard to grasp" so much as "hard to explain" or "easy to obfuscate." That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart.
  - copergi 13y ago
    >"hard to explain" or "easy to obfuscate." I wouldn't call it either of those things. They are so general that people have a hard time getting them. That's all. >That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart. That is not at all what the joke is getting at (and that doesn't even make sense).
  - kazagistar 13y ago
    I agree that they often make things seem harder then they really are. The monad tutorial that works best for me is the "don't mention monads" tutorial. Thats the one where you just show some specific task to complete, like composing (a -> Maybe b) functions, and show that there is a neat operator that does it. Then, at some future time, show another composition task, like composing (a -> [b]) functions, and show the same operator again. Starting with the abstract just messes people up and gets them confused. You don't start throwing around Kleisli Arrows and endofunctors right off the bat.
- dserban 13y ago
  From my own experience teaching Haskell, monads are incredibly hard to explain in terms that are easy for CS students with a systems programming background to understand. They are easy to explain to 2nd or 3rd year math students. The difference is in the audience's cognitive bias.
  - AnimalMuppet 13y ago
    If I understand correctly (and I may not), monads live in two different worlds. A (Haskell) monad has to be a (mathematical) monad. Haskell is counting on it not just to have certain function signatures, but to have certain properties - certain identities that it satisfies. This lets Haskell do some transformations under the hood. If you hand Haskell something that you say is a monad, and it doesn't satisfy the identities, you're going to get some really unpredictable results. That's the part that's easy to explain to 2nd or 3rd year math students. But, unless you're writing an application in group theory, as a programmer you don't really need a monad. You need something that will let you operate on a value that's in a Maybe, and therefore you need a monad. That is, you don't care about it being a monad for the sake of monads, you care about it as a way to solve a particular programming problem. That's the part that's hard to explain to CS students. They just want to operate on a Maybe. They don't understand why they have to care about it being a monad, or what the connection is between "monad" and "a kind of smuggler that will smuggle this function in to operate on a value that's stuck in jail in a Maybe" (or whatever analogy they're using). If you see a place my understanding can be improved, feel free to correct it...
davorak 13y ago
The monad tutorials the author is suggesting to avoid are those that make monad analogies. "Monad are like ..." because the analogies are always leaky and pretty much always gives some wrong impressions to beginners. The presentation here however just gives laws and usage examples. This approach makes it harder to give incorrect impressions to beginners.
- kyllo 13y ago
  This is my favorite monad analogy, though: "Monads are burritos?" http://chrisdone.com/posts/monads-are-burritos http://chrisdone.com/posts/monads-are-burritos
coolsunglasses 13y ago
Words confound the mind Concepts will obscure the truth Code alone brings forth http://lpaste.net/103140 http://lpaste.net/103140
drstrangevibes 13y ago
i dont know what the fuss is all about simply put monads are like a burrito wrapped in a spacesuit. fact.

I think it's kind of amusing that right after sternly warning the reader to avoid monad tutorials, he then proceeds to write a monad tutorial. I guess you just can't resist...

gamegoblin 13y ago

After I finally understood monads I thought about writing a tutorial. My thought process was "Well I understand it now, why couldn't someone have just explained it this way". Then I reevaluated and realized everyone has those thoughts. It's just a hard concept to grasp on the first try. One really just has to grind away and force themselves to use monads for a long enough time to really grok them.

username223 13y ago
I wouldn't call monads "hard to grasp" so much as "hard to explain" or "easy to obfuscate." That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart.
- copergi 13y ago
  >"hard to explain" or "easy to obfuscate." I wouldn't call it either of those things. They are so general that people have a hard time getting them. That's all. >That's what the "mumble mumble endofunctors" joke is getting at: sometimes they're a useful generalization, but more often they're a way to make easy things sound hard, or to make bad teachers sound smart. That is not at all what the joke is getting at (and that doesn't even make sense).
- kazagistar 13y ago
  I agree that they often make things seem harder then they really are. The monad tutorial that works best for me is the "don't mention monads" tutorial. Thats the one where you just show some specific task to complete, like composing (a -> Maybe b) functions, and show that there is a neat operator that does it. Then, at some future time, show another composition task, like composing (a -> [b]) functions, and show the same operator again. Starting with the abstract just messes people up and gets them confused. You don't start throwing around Kleisli Arrows and endofunctors right off the bat.
dserban 13y ago
From my own experience teaching Haskell, monads are incredibly hard to explain in terms that are easy for CS students with a systems programming background to understand. They are easy to explain to 2nd or 3rd year math students. The difference is in the audience's cognitive bias.
- AnimalMuppet 13y ago
  If I understand correctly (and I may not), monads live in two different worlds. A (Haskell) monad has to be a (mathematical) monad. Haskell is counting on it not just to have certain function signatures, but to have certain properties - certain identities that it satisfies. This lets Haskell do some transformations under the hood. If you hand Haskell something that you say is a monad, and it doesn't satisfy the identities, you're going to get some really unpredictable results. That's the part that's easy to explain to 2nd or 3rd year math students. But, unless you're writing an application in group theory, as a programmer you don't really need a monad. You need something that will let you operate on a value that's in a Maybe, and therefore you need a monad. That is, you don't care about it being a monad for the sake of monads, you care about it as a way to solve a particular programming problem. That's the part that's hard to explain to CS students. They just want to operate on a Maybe. They don't understand why they have to care about it being a monad, or what the connection is between "monad" and "a kind of smuggler that will smuggle this function in to operate on a value that's stuck in jail in a Maybe" (or whatever analogy they're using). If you see a place my understanding can be improved, feel free to correct it...

davorak 13y ago

The monad tutorials the author is suggesting to avoid are those that make monad analogies. "Monad are like ..." because the analogies are always leaky and pretty much always gives some wrong impressions to beginners. The presentation here however just gives laws and usage examples. This approach makes it harder to give incorrect impressions to beginners.

kyllo 13y ago
This is my favorite monad analogy, though: "Monads are burritos?" http://chrisdone.com/posts/monads-are-burritos http://chrisdone.com/posts/monads-are-burritos

coolsunglasses 13y ago

Words confound the mind Concepts will obscure the truth Code alone brings forth http://lpaste.net/103140 http://lpaste.net/103140

drstrangevibes 13y ago

i dont know what the fuss is all about simply put monads are like a burrito wrapped in a spacesuit. fact.