I suspect some people (not saying this author) butcher the explanation intentionally. Makes it seem like an ineffable topic that only the smartest programmer can understand.
For anyone unfamiliar, the `then` of Promises corresponds to the monadic `bind` or `flatMap` (if the given function returns a Promise) or the functorial `map` (if the given function returns a plain value).
A monad then is just the interface shared between Promises (`then` and `resolve`, collections (`flatMap` and `wrap`), etc.
The hard part for me was visualising the pattern for more complicated types like parsers (functions from strings to results) and continuations.
But there are some that do not. For instance, the "reverse state monad" would not make sense with 'bind' named 'then' since... as the name implies, state flows backwards through time in it!
Is there any reason to use monads in (let's say) Javascript rather than promises? Are there any performance gains?
Not intrinsically, IMO. The main value of monads is the shared interface, and its utility is contingent on tools that recognise that interface.
In that respect, it's as useful as providing e.g. a `map` method for promises, arrays, dictionaries, etc. Though in my experience JavaScript rarely seems to be written with this kind of generic interface in mind (e.g. there's no coherent interface mandated between classes in the standard library).
A little while ago there was an article (https://news.ycombinator.com/item?id=9907435) which suggested code like
if (cond1)
return val1;
if (cond2)
return val2;
if (cond3)
return val3;
return defaultVal;
if (cond1) {
return val1;
} else if (cond2) {
return val2;
} else if (cond3) {
return val3;
} else {
return defaultVal;
}
In any case, we can solve this conundrum through the existence of an Option or Maybe type which encapsulates the imperative behavior of short-circuiting failure directly and limits it's scope.
fa.then( f(ra) {
return fb(ra);
}).then( f(rb) {
return fc(rb);
})
ra <- fa()
rb <- fb(ra)
rc <- fb(rb)
I am kind of new to this so please bear with me. Thanks.
The idea is that from "inside", as we are using do-notation, we merely think of working in an imperative language where failure might occur and short circuit things while from "outside" we see the type of this computation as Maybe and can examine whether or not it actually failed. The "inside"/"outside" dynamic is the scope delimitation.