5 ms·

Yes, I can definitely explain monads to a 5-year old. See, a monad is like a box. You can put something in the box and close it very easily. But once it's clos

Yes, I can definitely explain monads to a 5-year old. See, a monad is like a box. You can put something in the box and close it very easily. But once it's closed, you can't open it anymore. The action of closing the box is called the wrap operation. What you _can_ do though, is tell someone else to do something to the thing inside the box. For example, if you put a toy in and close the box, you can ask a friend to go ahead and add a new one in. Or remove the toy. These are monadic functions. That's it. That's literally it. It's just a pattern of hiding the data and letting monadic functions be the only ones that deal with it. In the case of the Maybe monad for example, you'd have the unwrap function that tries to get whatever is inside out, but it might not be able to (if the box is empty).

taeric 4y ago
Not going to lie, I don't understand that explanation. It honestly sounds more like you are describing a form of encapsulation, as the contents of the box are hidden and someone else has the ability to open said box to get access to it. I also find the appeal to a physical object to explain a functional concept is rather amusing.
- solomonb 4y ago
  Not sure if you are looking for an explanation of Monads, but Monad tutorials are a long running joke in the haskell world. They are almost exclusively written by people for whom the concept just clicked and they either fail provide context for someone without that experience or they fail to actually describe the concept correctly. I'm not gonna give you an explanation but I will say that IMO the best way to actually learn about them is to just look at the typeclass and a bunch of instances of it and how they are used. If you ignore all the theory (and the "theory") and just look at the code you will find that they aren't that hard to sort out from a usage perspective.
  - taeric 4y ago
    Apologies, I seem to have deleted a sentence where I think I can make my understanding fit that metaphor. I don't think they are completely unapproachable, but I am not at all clear that a physical metaphor works. And, I really wanted to shine a light on the amusing appeal to physical objects in a thread that is about the short comings of object oriented programming. :D
    - solomonb 4y ago
      No need for apologies! I 100% agree that the physical metaphor doesn't work and said so in another nearby comment. If you go back to Phil Wadler's original paper on implementing monads in haskell, he doesn't talk about category theory or boxes or anything. He lays out a handful of common things you might do in programming but which seem totally unrelated. For each one he implements a solution and then reveals that all these solutions fit the same interface.
- ModernMech 4y ago
  > I also find the appeal to a physical object to explain a functional concept is rather amusing. The challenge was to describe it to a 5 year old. 5 year olds are better with concrete thinking than abstract reasoning. This is what made using the turtle in Logo a genius move, as it allowed younger children to write programs by conceptualizing a physical turtle that can move, rather than thinking in terms of an abstract function that mutates data.
  - taeric 4y ago
    Fair, and I don't necessarily disagree. I think this leads rather close to object oriented software being easier to reason about concretely than functional programming, though. And since most people are trying to get a concrete job done, that feels like a significant claim. For turtle geometry, it is also important to acknowledge the metaphor and shortcomings of a more traditionally analytic framing of drawings. Specifically, X and Y coordinates for a drawing are surprisingly hard to work with. For example, I challenge you to describe the fractal snow flake in an easier way than using directions as a metaphor. Same for the dragon curve. This can be seen akin to picking a different coordinate system, I presume?
- trebbble 4y ago
  At some point, it dawned on me that my problem wasn't that I didn't understand monads, it's that the idea's so simple I couldn't convince myself I understood it, and that what I actually didn't understand was why anyone gave a shit about them. Like if a bunch of smart people keep going on and on about something called a "floobiz", and every time they try to explain it to you, it just looks like a fucking cup. The problem isn't that you don't understand what a cup (floobiz) is, it's that you don't get why they keep going on about them like they're something special.
solomonb 4y ago
Unfortunately the container metaphor only works for a subset of monads. It fails with `IO`, `Reader`, `Writer`, `State`, `Parser`, etc.
- peoplefromibiza 4y ago
  how about we call the box wrapper and the operations on it computations? metaphors are good for beginners, to grasp the concept, they don't need to be perfectly valid. for example the popular OOP metaphor a car is a vehicle becomes useless pretty much immediately.
  - solomonb 4y ago
    IMO the metaphor is already getting too frayed at this point. I'm not opposed to metaphors in general, but metaphors are lot like abstractions. If you don't get the right one then the details leak everywhere and you may as well have not used it to begin with.
- AnimalMuppet 4y ago
  Well, for IO, it seems to me that maybe it still works. You're putting the entire external world in the box, but you're still (kind of?) doing the same thing.
- unsafecast 4y ago
  You might be right. I'll try a different way: You want to assemble a 16-piece puzzle, but there's too many of your friends around for you all to work on it at once, it would be a disaster. So you invent a game. The rules are: - Everyone only gets to put a single piece. There's 16 of your friends, so it works great. - You all sit in a row on the floor, and the puzzle gets passed from the last to the next. - Nobody can talk. All you can do is put a piece in and pass the puzzle. You then realize that there's actually 17 of you (you have 16 friends and forgot to count yourself) so every turn one of you sits at the end, receives the finished puzzle and checks it. It works great the first few times (you have _a lot_ of puzzles), but then something happens. One of your friends lost a piece. They can't talk, so they just panic and the turn ends. What you need to do is change the game a bit so this doesn't happen again (it's better to get no puzzle than a panicked friend). So you add two rules: - If you can't add your piece for some reason, you pass a piece of paper saying why instead of the puzzle. - If you receive a piece of paper, pass it to the next person. With everyone equipped with the paper and the piece, the next turn starts. Your friend lost their piece again, but there's no problem: you've got a lot of puzzles, and more importantly, your friend knows what to do. They write ‘I lost my piece’, and give the paper to the next person. You, sitting at the end, receive the piece of paper and know exactly what happened. Congratulations, that's the Either monad with a puzzle as the Right, and a piece of inscribed paper as the Left, and the ‘bind’ operation is the rule set that explains how you communicate with the next person. You can use the same kind of explanation for State, except you come up with a game that uses the same object as the state and every ‘friend’ makes something different that the next one needs. Note: Saying you lost your piece out loud would be like throwing an exception. I guess you can re-use this as an explanation for that.

taeric 4y ago

Not going to lie, I don't understand that explanation. It honestly sounds more like you are describing a form of encapsulation, as the contents of the box are hidden and someone else has the ability to open said box to get access to it. I also find the appeal to a physical object to explain a functional concept is rather amusing.

solomonb 4y ago
Not sure if you are looking for an explanation of Monads, but Monad tutorials are a long running joke in the haskell world. They are almost exclusively written by people for whom the concept just clicked and they either fail provide context for someone without that experience or they fail to actually describe the concept correctly. I'm not gonna give you an explanation but I will say that IMO the best way to actually learn about them is to just look at the typeclass and a bunch of instances of it and how they are used. If you ignore all the theory (and the "theory") and just look at the code you will find that they aren't that hard to sort out from a usage perspective.
- taeric 4y ago
  Apologies, I seem to have deleted a sentence where I think I can make my understanding fit that metaphor. I don't think they are completely unapproachable, but I am not at all clear that a physical metaphor works. And, I really wanted to shine a light on the amusing appeal to physical objects in a thread that is about the short comings of object oriented programming. :D
  - solomonb 4y ago
    No need for apologies! I 100% agree that the physical metaphor doesn't work and said so in another nearby comment. If you go back to Phil Wadler's original paper on implementing monads in haskell, he doesn't talk about category theory or boxes or anything. He lays out a handful of common things you might do in programming but which seem totally unrelated. For each one he implements a solution and then reveals that all these solutions fit the same interface.
ModernMech 4y ago
> I also find the appeal to a physical object to explain a functional concept is rather amusing. The challenge was to describe it to a 5 year old. 5 year olds are better with concrete thinking than abstract reasoning. This is what made using the turtle in Logo a genius move, as it allowed younger children to write programs by conceptualizing a physical turtle that can move, rather than thinking in terms of an abstract function that mutates data.
- taeric 4y ago
  Fair, and I don't necessarily disagree. I think this leads rather close to object oriented software being easier to reason about concretely than functional programming, though. And since most people are trying to get a concrete job done, that feels like a significant claim. For turtle geometry, it is also important to acknowledge the metaphor and shortcomings of a more traditionally analytic framing of drawings. Specifically, X and Y coordinates for a drawing are surprisingly hard to work with. For example, I challenge you to describe the fractal snow flake in an easier way than using directions as a metaphor. Same for the dragon curve. This can be seen akin to picking a different coordinate system, I presume?
trebbble 4y ago
At some point, it dawned on me that my problem wasn't that I didn't understand monads, it's that the idea's so simple I couldn't convince myself I understood it, and that what I actually didn't understand was why anyone gave a shit about them. Like if a bunch of smart people keep going on and on about something called a "floobiz", and every time they try to explain it to you, it just looks like a fucking cup. The problem isn't that you don't understand what a cup (floobiz) is, it's that you don't get why they keep going on about them like they're something special.

solomonb 4y ago

Unfortunately the container metaphor only works for a subset of monads. It fails with `IO`, `Reader`, `Writer`, `State`, `Parser`, etc.

peoplefromibiza 4y ago
how about we call the box wrapper and the operations on it computations? metaphors are good for beginners, to grasp the concept, they don't need to be perfectly valid. for example the popular OOP metaphor a car is a vehicle becomes useless pretty much immediately.
- solomonb 4y ago
  IMO the metaphor is already getting too frayed at this point. I'm not opposed to metaphors in general, but metaphors are lot like abstractions. If you don't get the right one then the details leak everywhere and you may as well have not used it to begin with.
AnimalMuppet 4y ago
Well, for IO, it seems to me that maybe it still works. You're putting the entire external world in the box, but you're still (kind of?) doing the same thing.
unsafecast 4y ago
You might be right. I'll try a different way: You want to assemble a 16-piece puzzle, but there's too many of your friends around for you all to work on it at once, it would be a disaster. So you invent a game. The rules are: - Everyone only gets to put a single piece. There's 16 of your friends, so it works great. - You all sit in a row on the floor, and the puzzle gets passed from the last to the next. - Nobody can talk. All you can do is put a piece in and pass the puzzle. You then realize that there's actually 17 of you (you have 16 friends and forgot to count yourself) so every turn one of you sits at the end, receives the finished puzzle and checks it. It works great the first few times (you have _a lot_ of puzzles), but then something happens. One of your friends lost a piece. They can't talk, so they just panic and the turn ends. What you need to do is change the game a bit so this doesn't happen again (it's better to get no puzzle than a panicked friend). So you add two rules: - If you can't add your piece for some reason, you pass a piece of paper saying why instead of the puzzle. - If you receive a piece of paper, pass it to the next person. With everyone equipped with the paper and the piece, the next turn starts. Your friend lost their piece again, but there's no problem: you've got a lot of puzzles, and more importantly, your friend knows what to do. They write ‘I lost my piece’, and give the paper to the next person. You, sitting at the end, receive the piece of paper and know exactly what happened. Congratulations, that's the Either monad with a puzzle as the Right, and a piece of inscribed paper as the Left, and the ‘bind’ operation is the rule set that explains how you communicate with the next person. You can use the same kind of explanation for State, except you come up with a game that uses the same object as the state and every ‘friend’ makes something different that the next one needs. Note: Saying you lost your piece out loud would be like throwing an exception. I guess you can re-use this as an explanation for that.