You say "by wrapping a value" and then confuse it with the wrapper right away.
No, monads are not wrappers. Some wrappers are monads, but not all.
inb4, monads are not pipes either.
Sure, a monad is a type constructor. The constructed type allows you to compose transformations.
Each monad constructs a type that behaves differently and expects different things, but in general; the monad is defined by a unit/point/return function which brings a value into the monadic context, and a flatMap function aka bind, which further breaks down to “flatten after map”.
So List[_] is a type constructor, given a type T, it produces a List[T], which defines some transformations. Return creates a single element list, and flatmap takes the A->[B] applies it everywhere and then concatenates.
The nice thing about the wrapper analogy is that even though it is technically wrong, it is easier for people to get it because it follows naturally from OOP and it is a sufficiently useful mental model imho.
IMO the spirit of this answer is a big part of the problem. This might not be exactly what the GP was saying but I've found you can quickly get a dev up to speed with a "good enough" sense of what a monad is. One that'd cover a vast majority of their needs, at least in the early going.
But then there are always people who start popping in and pointing out how those definitions aren't quite right. Which is true. But does it matter *for practical purposes* to give a dev a useful for now mental model that they can then use to figure the rest out later? I'd say no.
Then why not just say that a monad (instance) is a type `t` which implements `bind :: t a -> (a -> t b) -> t b`? It's as down to earth and down to the point as it gets, and each time a new dev thinks out a code path which would lead to `t b` they'd remember `bind`. No need for containers metaphors at all.
For practical purposes you don't have to know what the monad "is". You need some good practical examples how to wield them.
Knowing some prehistory about doesn't affect usage. And metaphors are very tricky and personal.
The personal part is where the "monad tutorials" fall flat. They assume shared context which may or not may not be actually shared by a random reader on the internet. Yes, some monads are really about "wrapping a value" or whatever.
Reading a post using this metaphor when you want such a wrapping and/or deal with chaining wrappers regularly can bootstrap your understanding in no time. But if you're reading "wrapper"-flavored tutorial while dealing with "pipes" then the spell breaks, you end up confused, and another one joins the "monads are uncomprehensible" group.
Teaching is hard enough. Writing good tutorials is even harder. Successfully giving an universally good drive-by explanation is next to zero probability.
I suspect this is a knowledge variant of "XY problem" and you have to establish more context before answering.
And another problem that "what is a monad" is already a meme. Everyone has the burning desire to ask it, but usually there's no practical need for the answer. Without that confusion ensues. Or, even worse, a false understanding gets locked in and starts to proliferate, sustaining the memetic chain reaction.
PartiallyTyped|2 years ago
Each monad constructs a type that behaves differently and expects different things, but in general; the monad is defined by a unit/point/return function which brings a value into the monadic context, and a flatMap function aka bind, which further breaks down to “flatten after map”.
So List[_] is a type constructor, given a type T, it produces a List[T], which defines some transformations. Return creates a single element list, and flatmap takes the A->[B] applies it everywhere and then concatenates.
The nice thing about the wrapper analogy is that even though it is technically wrong, it is easier for people to get it because it follows naturally from OOP and it is a sufficiently useful mental model imho.
jghn|2 years ago
But then there are always people who start popping in and pointing out how those definitions aren't quite right. Which is true. But does it matter *for practical purposes* to give a dev a useful for now mental model that they can then use to figure the rest out later? I'd say no.
bPspGiJT8Y|2 years ago
icrbow|2 years ago
Knowing some prehistory about doesn't affect usage. And metaphors are very tricky and personal.
The personal part is where the "monad tutorials" fall flat. They assume shared context which may or not may not be actually shared by a random reader on the internet. Yes, some monads are really about "wrapping a value" or whatever.
Reading a post using this metaphor when you want such a wrapping and/or deal with chaining wrappers regularly can bootstrap your understanding in no time. But if you're reading "wrapper"-flavored tutorial while dealing with "pipes" then the spell breaks, you end up confused, and another one joins the "monads are uncomprehensible" group.
Teaching is hard enough. Writing good tutorials is even harder. Successfully giving an universally good drive-by explanation is next to zero probability.
I suspect this is a knowledge variant of "XY problem" and you have to establish more context before answering.
And another problem that "what is a monad" is already a meme. Everyone has the burning desire to ask it, but usually there's no practical need for the answer. Without that confusion ensues. Or, even worse, a false understanding gets locked in and starts to proliferate, sustaining the memetic chain reaction.
PartiallyTyped|2 years ago