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.
