4 ms·

Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` So it's

Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" Gilad Bracha covered this in a talk once. Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body. So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."

bitwize 8y ago
> Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" It's a joke/dank maymay that Haskells still find funny long after it's pissed everyone else off. The idea is that since category theory is described as "generalized abstract nonsense" by its practitioners, describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation and you just come off sounding like a dick.
- stcredzero 8y ago
  The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation Who needs mindshare, when you can have in-jokes instead? Better to be the one everyone initially laughs at, but wind up with all the mindshare, than to be the one doing all the laughing who gets left behind.
  - derefr 8y ago
    It's not quite an in-joke. It's in-gallows humour: something common to all transmission of hard-to-communicate knowledge. Anyone on the far side of a gulf of enlightenment—and understanding monads is an enlightenment, if a small one—knows that it's effectively impossible to actually communicate the particular thing they learned that helped them achieve enlightenment. (Well, it's not impossible to communicate what they learned; it's just that that's roughly useless to anyone else. An enlightenment is a realization that culminates only from all of a set of micro-skills being attained; and each person is missing different micro-skills to start with. You can look back and see the micro-skills you learned, and teach those, but you have no idea what micro-skills you started off already in possession of that others did not—what micro-skills you take for granted—and so you cannot teach those.) When faced with someone starting on the path to an enlightenment, who asks you to simply summarize the path for them, there's no way to actually usefully tell them. But it's kind of rude to just say nothing—and on a forum like this, equally rude to assume a role of a master verbally lashing an apprentice (ala a Zen parable) for assuming they could understand the concept without working their brain up through all the micro-skills it was missing first. So, what you do instead is, you make a joke. A joke that seems opaque at the time, but which the learner, having journeyed further down the path, will realize was the truth they sought, and exactly what they asked for—it was just a truth that was, necessarily, completely useless to them at the time. Any such truth would be. You don't make the joke to be snarky. You make the joke because you wish that, this time, it would work, and the learner would skip the path and achieve the enlightenment; that you could just reach across the gulf and bring them over. But you know it won't. The punchline of the "joke" is not played on the learner, but on the teacher: it is that the world is cruel and to teach skills that require enlightenments is to suffer knowing your students lay across this gulf, and most of what you say will miss them entirely because of the mismatch in micro-skill acquisition between you. (Though, I suppose, when the learner attempts to teach the concept themselves, and realizes the only thing they want to say is the same useless thing that was said to them—this would be the joke "paying off." That pay-off makes it sort of like a traditional joke, in the sense that choosing to "tell" it rather than simply thinking it to oneself is choosing to set the learner up for that later pay-off.)
    - 8y ago
- alexmorenodev 8y ago
  As a "never touched any functional language but always hear about how monads are extremely complex", I feel enlighted.
- marcosdumay 8y ago
  > category theory is described as "generalized abstract nonsense" by its practitioners That should be more accessible for people trying to learn it. The idea that "category" by itself is something that is supposed to be completely devoid of meaning is not clear at first. This slowed me down a lot when learning.
- eapriv 8y ago
  > describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. I am a counterexample: the description of a monad as a monoid in the category of endofunctors actually helped me, especially when I was new to Haskell. I am a mathematician, and happen to know category theory enough to appreciate this description. Also, I am a little tired of hearing "you don't have to know category theory in order to learn Haskell". What if I already DO know category theory? I wish someone wrote a tutorial or a book explaining Haskell to mathematically inclined readers and not dismissing (in a kind of anti-intellectual way) simple algebra as "useless abstractions".
jerf 8y ago
'So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?"' "Monad" seems to be just beyond the complexity event horizon where it is difficult for people to get a really clean idea of what it is, so instead we've got dozens of ideas of what they are floating around, probably a good two-thirds of them with fundamental errors in them, which then contributes to the general haze surrounding the ideas. I've got a mostly-written blog post on deck with the tentative title "Functors and Monads For People Who Have Read Too Many Tutorials", for which around 80% of it isn't explaining what they are, but systematically walking through all the errors I've seen (some of which are in the type notation for Haskell itself; the "[a]" abbreviation for what should be "[] a", if not "List a", alone has done untold damage to comprehension) before finally getting down to what the things are. (Functor in particular is so trivial it's hard to believe it's that trivial when you finally really get it. Monad legitimately has a bit of a twist in it, and some of the specific uses of that interface take that twist and hammer it home to produce some very funky code, so the fact that it's a bit foggy isn't that big a surprise. The fog that functor has picked up by association with monad is much, much larger than the concept itself, though.) "So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time." It turns out no, that's just one use of them. A very big one, a very natural one, and the one that drove their prominence in the current debate... but it's not actually what the interface is "about" per se. For a good counterexample, consider the parsing monad implementations that "declaratively" [1] create a parser. It's not really about declaring execution sequences. (There's also a non-trivial amount of confusion that arises from the fact that monad and laziness have a lot of interaction. The monad interface in a strict language would be used differently than it can be in Haskell.)
- Serow225 8y ago
  I would love to read that post, the title describes exactly the boat I'm in :) how can I subscribe so I don't miss it?
  - jerf 8y ago
    http://jerf.org/iri/rss.xml http://jerf.org/iri/rss.xml
marcosdumay 8y ago
A monad is a standard interface for the Interpreter pattern. That's why you would want it. That's what you gain from them. It is a very easy standard to implement if your interpreter is simple, it can be composed into more complex interpreters, and languages that support it come with many basic implementations that you can use to construct something more complex. The mathematicians are saying basically the same thing, but from another point of view (monoid on the category of endofunctors means computations, with an environment, that you can join one after the other) that focus much more on standards than on usability, and much more on formality than on how to make large structures out of it, so the names are different.
the_af 8y ago
> "Gilad Bracha covered this in a talk once." Note that Bracha, knowledgeable as he is in his areas of interest, is painfully dismissive of things he does not understand. I watched that talk where he mentions monads (as well as non-optional static type systems, another subject he dislikes), and he comes across as ignorant and dismissive. I wouldn't use his opinions on these subjects as evidence of anything.
pwm 8y ago
Realising that a monad is just a lax functor from a terminal bicategory also helps.
lmm 8y ago
> So it's a wrapper that implements a particular interface? There's no wrapper, and "interface" is misleading since it suggests something that lets you invoke methods on instances whereas actually one of the core monad functions (pure aka point aka return) is something you call with a value that currently has no connection to the monad. > Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" The categorical thing is just a joke. It's hard to talk about monads in general because they're very generic, and unfortunately IO is one of the most "monadey" of them all: it's a monad and essentially nothing else. The best way to learn to work with IO is probably to learn to work with other monads first - option or either or writer or state, things that have a canonical presentation in terms of normal functions and values. Unfortunately, even though I/O is a tiny fraction of real-world business programming (when was the last time you actually used "getChar" at your day job?), it's where people tend to start programming. > So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly." You've got it backwards. It's a way of expressing operations that lets you reason as if you were calling imperative procedures most of the time, but they are and will always remain be pure functions in a guaranteed sense that you can fall back on. There is nothing "mostly" about it and this is really important, it's what makes functional programming so useful.
- agentultra 8y ago
  > There's no wrapper, and "interface" is misleading True. I used a convenient lie to make a point. If you're interested in learning Monads you should definitely learn it from a proper source like Haskell from First Principles [0], an online course, or someone who really knows what they're talking about. As I only alluded to and others have pointed out: there's nothing about monads that's inherently sequential or having to do with ordering operations. That's just how the language defined the interpretation of the IO monad. And it also happens that this is the primary topic of concern of TFA. You might even come to realize that much of what a Monad isn't contradicts the entire premise of TFA... Haskell doesn't even need the IO monad and could implement IO other ways just fine [1]. [0] https://haskellbook.com https://haskellbook.com [1] https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/ https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-...
machiavelli1024 8y ago
>So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. No. Monad is just a “design pattern”. It’s nice that this design pattern happens to be useful to force sequential evaluation, but it’s just one of the many things that fits the monad abstraction.
didibus 8y ago
> So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout... Its because its actually a mathematical concept. And that's the mathematical definition. So Haskell decided to use the same name. Now some people feel, should I explain the math concept, or its concrete representation in Haskell. Also, its a bit more involved as an interface. In that its not enough to implement the common methods for the interface. You also have to prove that your implementation for each exhibit certain properties, specifically there needs to be an identity value which act as a neutral element, and they must be associative. Those laws are where things get more mathematical. Because its rare in comp-sci to talk about laws and properties of functions.

bitwize 8y ago

> Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" It's a joke/dank maymay that Haskells still find funny long after it's pissed everyone else off. The idea is that since category theory is described as "generalized abstract nonsense" by its practitioners, describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation and you just come off sounding like a dick.

stcredzero 8y ago
The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation Who needs mindshare, when you can have in-jokes instead? Better to be the one everyone initially laughs at, but wind up with all the mindshare, than to be the one doing all the laughing who gets left behind.
- derefr 8y ago
  It's not quite an in-joke. It's in-gallows humour: something common to all transmission of hard-to-communicate knowledge. Anyone on the far side of a gulf of enlightenment—and understanding monads is an enlightenment, if a small one—knows that it's effectively impossible to actually communicate the particular thing they learned that helped them achieve enlightenment. (Well, it's not impossible to communicate what they learned; it's just that that's roughly useless to anyone else. An enlightenment is a realization that culminates only from all of a set of micro-skills being attained; and each person is missing different micro-skills to start with. You can look back and see the micro-skills you learned, and teach those, but you have no idea what micro-skills you started off already in possession of that others did not—what micro-skills you take for granted—and so you cannot teach those.) When faced with someone starting on the path to an enlightenment, who asks you to simply summarize the path for them, there's no way to actually usefully tell them. But it's kind of rude to just say nothing—and on a forum like this, equally rude to assume a role of a master verbally lashing an apprentice (ala a Zen parable) for assuming they could understand the concept without working their brain up through all the micro-skills it was missing first. So, what you do instead is, you make a joke. A joke that seems opaque at the time, but which the learner, having journeyed further down the path, will realize was the truth they sought, and exactly what they asked for—it was just a truth that was, necessarily, completely useless to them at the time. Any such truth would be. You don't make the joke to be snarky. You make the joke because you wish that, this time, it would work, and the learner would skip the path and achieve the enlightenment; that you could just reach across the gulf and bring them over. But you know it won't. The punchline of the "joke" is not played on the learner, but on the teacher: it is that the world is cruel and to teach skills that require enlightenments is to suffer knowing your students lay across this gulf, and most of what you say will miss them entirely because of the mismatch in micro-skill acquisition between you. (Though, I suppose, when the learner attempts to teach the concept themselves, and realizes the only thing they want to say is the same useless thing that was said to them—this would be the joke "paying off." That pay-off makes it sort of like a traditional joke, in the sense that choosing to "tell" it rather than simply thinking it to oneself is choosing to set the learner up for that later pay-off.)
  - 8y ago
alexmorenodev 8y ago
As a "never touched any functional language but always hear about how monads are extremely complex", I feel enlighted.
marcosdumay 8y ago
> category theory is described as "generalized abstract nonsense" by its practitioners That should be more accessible for people trying to learn it. The idea that "category" by itself is something that is supposed to be completely devoid of meaning is not clear at first. This slowed me down a lot when learning.
eapriv 8y ago
> describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. I am a counterexample: the description of a monad as a monoid in the category of endofunctors actually helped me, especially when I was new to Haskell. I am a mathematician, and happen to know category theory enough to appreciate this description. Also, I am a little tired of hearing "you don't have to know category theory in order to learn Haskell". What if I already DO know category theory? I wish someone wrote a tutorial or a book explaining Haskell to mathematically inclined readers and not dismissing (in a kind of anti-intellectual way) simple algebra as "useless abstractions".

jerf 8y ago

'So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?"' "Monad" seems to be just beyond the complexity event horizon where it is difficult for people to get a really clean idea of what it is, so instead we've got dozens of ideas of what they are floating around, probably a good two-thirds of them with fundamental errors in them, which then contributes to the general haze surrounding the ideas. I've got a mostly-written blog post on deck with the tentative title "Functors and Monads For People Who Have Read Too Many Tutorials", for which around 80% of it isn't explaining what they are, but systematically walking through all the errors I've seen (some of which are in the type notation for Haskell itself; the "[a]" abbreviation for what should be "[] a", if not "List a", alone has done untold damage to comprehension) before finally getting down to what the things are. (Functor in particular is so trivial it's hard to believe it's that trivial when you finally really get it. Monad legitimately has a bit of a twist in it, and some of the specific uses of that interface take that twist and hammer it home to produce some very funky code, so the fact that it's a bit foggy isn't that big a surprise. The fog that functor has picked up by association with monad is much, much larger than the concept itself, though.) "So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time." It turns out no, that's just one use of them. A very big one, a very natural one, and the one that drove their prominence in the current debate... but it's not actually what the interface is "about" per se. For a good counterexample, consider the parsing monad implementations that "declaratively" [1] create a parser. It's not really about declaring execution sequences. (There's also a non-trivial amount of confusion that arises from the fact that monad and laziness have a lot of interaction. The monad interface in a strict language would be used differently than it can be in Haskell.)

Serow225 8y ago
I would love to read that post, the title describes exactly the boat I'm in :) how can I subscribe so I don't miss it?
- jerf 8y ago
  http://jerf.org/iri/rss.xml http://jerf.org/iri/rss.xml

marcosdumay 8y ago

A monad is a standard interface for the Interpreter pattern. That's why you would want it. That's what you gain from them. It is a very easy standard to implement if your interpreter is simple, it can be composed into more complex interpreters, and languages that support it come with many basic implementations that you can use to construct something more complex. The mathematicians are saying basically the same thing, but from another point of view (monoid on the category of endofunctors means computations, with an environment, that you can join one after the other) that focus much more on standards than on usability, and much more on formality than on how to make large structures out of it, so the names are different.

the_af 8y ago

> "Gilad Bracha covered this in a talk once." Note that Bracha, knowledgeable as he is in his areas of interest, is painfully dismissive of things he does not understand. I watched that talk where he mentions monads (as well as non-optional static type systems, another subject he dislikes), and he comes across as ignorant and dismissive. I wouldn't use his opinions on these subjects as evidence of anything.

pwm 8y ago

Realising that a monad is just a lax functor from a terminal bicategory also helps.

lmm 8y ago

> So it's a wrapper that implements a particular interface? There's no wrapper, and "interface" is misleading since it suggests something that lets you invoke methods on instances whereas actually one of the core monad functions (pure aka point aka return) is something you call with a value that currently has no connection to the monad. > Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" The categorical thing is just a joke. It's hard to talk about monads in general because they're very generic, and unfortunately IO is one of the most "monadey" of them all: it's a monad and essentially nothing else. The best way to learn to work with IO is probably to learn to work with other monads first - option or either or writer or state, things that have a canonical presentation in terms of normal functions and values. Unfortunately, even though I/O is a tiny fraction of real-world business programming (when was the last time you actually used "getChar" at your day job?), it's where people tend to start programming. > So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly." You've got it backwards. It's a way of expressing operations that lets you reason as if you were calling imperative procedures most of the time, but they are and will always remain be pure functions in a guaranteed sense that you can fall back on. There is nothing "mostly" about it and this is really important, it's what makes functional programming so useful.

agentultra 8y ago
> There's no wrapper, and "interface" is misleading True. I used a convenient lie to make a point. If you're interested in learning Monads you should definitely learn it from a proper source like Haskell from First Principles [0], an online course, or someone who really knows what they're talking about. As I only alluded to and others have pointed out: there's nothing about monads that's inherently sequential or having to do with ordering operations. That's just how the language defined the interpretation of the IO monad. And it also happens that this is the primary topic of concern of TFA. You might even come to realize that much of what a Monad isn't contradicts the entire premise of TFA... Haskell doesn't even need the IO monad and could implement IO other ways just fine [1]. [0] https://haskellbook.com https://haskellbook.com [1] https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/ https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-...

machiavelli1024 8y ago

>So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. No. Monad is just a “design pattern”. It’s nice that this design pattern happens to be useful to force sequential evaluation, but it’s just one of the many things that fits the monad abstraction.

didibus 8y ago

> So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout... Its because its actually a mathematical concept. And that's the mathematical definition. So Haskell decided to use the same name. Now some people feel, should I explain the math concept, or its concrete representation in Haskell. Also, its a bit more involved as an interface. In that its not enough to implement the common methods for the interface. You also have to prove that your implementation for each exhibit certain properties, specifically there needs to be an identity value which act as a neutral element, and they must be associative. Those laws are where things get more mathematical. Because its rare in comp-sci to talk about laws and properties of functions.