You don't need to really understand monads to use them. Not at first anyway. They're basically just containers that allow you to use side effects, hold state, etc... https://acm.wustl.edu/functional/io-monad.jpg
I'm going to make an attempt to succinctly explain monads:
A monadic data type is a container that can be mapped and flattened.
- It's a container, because it stores has an inner type, which refers to the data it contains. For example, think of the type parameter that describes the elements of a list.
- It is "mappable" in the sense that its contained type can be converted to another type by providing an operation from the first type to the second type. Imagine converting a list of strings to a list of integers, where each integer is the length of the corresponding string.
- It can be "flattened" in the sense that if its inner type is an extra nesting of the container type, it can be flattened to a just one level of the container type. For example, a list of lists of integers can be flattened to just a list of integers by concatenating the sublists.
- It seems kind of trivial to say, but there has to be a way to construct a container given one of the elements it's supposed to contain.
There are also a couple of rule these operations have to fulfill. They're kind of abstract when stated on their own, but make intuitive sense when you consider examples.
Pretty simple, huh? What's cool about it is that you can assign all sorts of metadata to the container type and semantics to the flatten operation, and you get a nice representation of a pipeline of operations, where each one depends on the all the previous steps. This is basically just imperative programming -- each step depends on the current context and can optionally mutate that context, affecting subsequent steps.
You might ask, "but isn't imperative programming what we're trying not to do?" In the most general sense with mutable state everywhere, yes. But monads give you a way to describe imperative logic in very tightly controlled contexts.
> 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".
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.
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)
>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.
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.
>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.
> 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?
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?
New abstractions are generally better introduced to new audiences via concrete examples that can later be generalized rather than formal abstractions that float high above our heads.
The GP's explanation of the concrete features (with simple examples!) is one of the most useful explanations of monads I've seen. It isn't complete, but as a gateway to a complete explanation it is extremely good.
