5 ms·

> A Monad is just something that has a bind (>>=) function and a return function. You realise that this is the most useless description ever? While I'm sure it

> A Monad is just something that has a bind (>>=) function and a return function. You realise that this is the most useless description ever? While I'm sure it's right, it doesn't actually mean anything. Why's it a good abstraction for doing <X>, better than any other abstraction? If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the language a lot simpler to use)? Your description is on the same level as "programming languages are structured text".

thedufer 12y ago
The point, I think, is that the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc.
- the_af 12y ago
  Fully agreed that those are the easiest monads, far easier than IO, state and side-effects. But the post is still unhelpful, because how do List and Maybe relate to this: > A Monad is just something that has a bind (>>=) function and a return function. ? (I know how they relate, but the above assertion is not a particularly helpful description of List and Maybe)
  - wyager 12y ago
    >but the above assertion is not a particularly helpful description of List and Maybe Good. If my description of a Monad was a good description of List or Maybe, then I described Monads wrong. Your complaint is like saying "Your description of a shape was not a helpful description of a dodecahedron." Indeed, a dodecahedron is a very specific instance of a shape.
    - the_af 12y ago
      Exactly. However, note I wasn't disagreeing with you; I was disagreeing with user thedufer that "the point" was that "the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc." (That's why I replied to him and not to you) List and Maybe are indeed the easiest monads, but thinking about them in terms of (>>=) and return doesn't give a good intuition about monads, Lists or Maybe. So I think that wasn't "the point". "The point" was actually that state and IO aren't the only monads, and that the definition is way more general than that. List and Maybe being the easiest monads is irrelevant.
      - wyager 12y ago
        Gotcha. Then I am in absolute agreement.
wyager 12y ago
>You realise that this is the most useless description ever? Which is perhaps why many people have a hard time understanding it. That is, however, the true definition. >Why's it a good abstraction for doing <X> That depends on <X>. I can't answer that question unless you tell me what <X> is. > If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the language a lot simpler to use)? Why would a special-purpose abstraction be easier to use? If you only understand monads in terms of state, you can just use them that way.
- vertex-four 12y ago
  > That depends on <X>. I can't answer that question unless you tell me what <X> is. Isn't that kind of the problem? I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. Is it a good abstraction for adding numbers together? God knows, nobody can explain it. > Why would a special-purpose abstraction be easier to use? Because it says what it does on the tin, rather than being buried under several abstraction layers. My for loop is a lot more obvious than your "lifting functions into the list monad" or whatever it is you do with them, and is quite obviously doing an entirely different thing from, say, dealing with the contents of a Maybe, or storing state, or executing IO operations. We can play with abstractions upon abstractions all day, but unless they actually mean something solid, how are they useful in explaining or solving a problem?
  - wyager 12y ago
    >Isn't that kind of the problem? Maybe. Leaving things in the abstract can certainly be confusing sometimes. >I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. I think once you understand Monads for what they are (i.e. accept that it's just something with bind and return), you start seeing where it makes sense to use Monads. Until then, you can just use whatever concrete Monad implementations you're aware of. It seems like you know perfectly well that there exist Monad implementations for Lists, for example. > Because it says what it does on the tin, rather than being buried under several abstraction layers. IO, List, and most other Monads do what they say on the tin, even if you're not aware that they're Monads. You don't have to know if something is a Monad or not to use it. For example, I've been using Lists my entire programming career without it occurring to me that I could use them with bind to model nondeterminism or the ZipList Monad. >but unless they actually mean something solid, how are they useful in explaining or solving a problem? They are useful because they are examples of http://en.wikipedia.org/wiki/Algebraic_structure http://en.wikipedia.org/wiki/Algebraic_structure . You can use the definition of an algebraic structure to prove things about all instances of that structure. Monads are, in fact, quite useful even in their most general definition.

thedufer 12y ago

The point, I think, is that the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc.

the_af 12y ago
Fully agreed that those are the easiest monads, far easier than IO, state and side-effects. But the post is still unhelpful, because how do List and Maybe relate to this: > A Monad is just something that has a bind (>>=) function and a return function. ? (I know how they relate, but the above assertion is not a particularly helpful description of List and Maybe)
- wyager 12y ago
  >but the above assertion is not a particularly helpful description of List and Maybe Good. If my description of a Monad was a good description of List or Maybe, then I described Monads wrong. Your complaint is like saying "Your description of a shape was not a helpful description of a dodecahedron." Indeed, a dodecahedron is a very specific instance of a shape.
  - the_af 12y ago
    Exactly. However, note I wasn't disagreeing with you; I was disagreeing with user thedufer that "the point" was that "the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc." (That's why I replied to him and not to you) List and Maybe are indeed the easiest monads, but thinking about them in terms of (>>=) and return doesn't give a good intuition about monads, Lists or Maybe. So I think that wasn't "the point". "The point" was actually that state and IO aren't the only monads, and that the definition is way more general than that. List and Maybe being the easiest monads is irrelevant.
    - wyager 12y ago
      Gotcha. Then I am in absolute agreement.

wyager 12y ago

>You realise that this is the most useless description ever? Which is perhaps why many people have a hard time understanding it. That is, however, the true definition. >Why's it a good abstraction for doing <X> That depends on <X>. I can't answer that question unless you tell me what <X> is. > If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the language a lot simpler to use)? Why would a special-purpose abstraction be easier to use? If you only understand monads in terms of state, you can just use them that way.

vertex-four 12y ago
> That depends on <X>. I can't answer that question unless you tell me what <X> is. Isn't that kind of the problem? I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. Is it a good abstraction for adding numbers together? God knows, nobody can explain it. > Why would a special-purpose abstraction be easier to use? Because it says what it does on the tin, rather than being buried under several abstraction layers. My for loop is a lot more obvious than your "lifting functions into the list monad" or whatever it is you do with them, and is quite obviously doing an entirely different thing from, say, dealing with the contents of a Maybe, or storing state, or executing IO operations. We can play with abstractions upon abstractions all day, but unless they actually mean something solid, how are they useful in explaining or solving a problem?
- wyager 12y ago
  >Isn't that kind of the problem? Maybe. Leaving things in the abstract can certainly be confusing sometimes. >I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. I think once you understand Monads for what they are (i.e. accept that it's just something with bind and return), you start seeing where it makes sense to use Monads. Until then, you can just use whatever concrete Monad implementations you're aware of. It seems like you know perfectly well that there exist Monad implementations for Lists, for example. > Because it says what it does on the tin, rather than being buried under several abstraction layers. IO, List, and most other Monads do what they say on the tin, even if you're not aware that they're Monads. You don't have to know if something is a Monad or not to use it. For example, I've been using Lists my entire programming career without it occurring to me that I could use them with bind to model nondeterminism or the ZipList Monad. >but unless they actually mean something solid, how are they useful in explaining or solving a problem? They are useful because they are examples of http://en.wikipedia.org/wiki/Algebraic_structure http://en.wikipedia.org/wiki/Algebraic_structure . You can use the definition of an algebraic structure to prove things about all instances of that structure. Monads are, in fact, quite useful even in their most general definition.