My guess is that all the people praising this article already "got monads". But for the unenlightened, it doesn't do anything.
Sure it does, it provides a pragmatic rather than abstract answer to the question “what are monads”.
> It's just a list of statements. "This is bad, that is good." But it doesn't explain why the bad things are bad, and how using monads is better.
As I see it, that's because it's based on targeting an audience in which:
(1) it is widely accepted that the “Hell” things are bad, and
(2) it is widely accepted that simple, general solutions to broad classes of problems are better than myriad special solutions to narrow subsets.
> It also doesn't explain what monads are.
Not in the abstract sense; otoh, the whole piece is a pragmatic explanation of what monads are: the common solution to an array of problems for which a series of examples is provided.
On the level the article seeks to explain? Yes, sure.
On the abstract level lots of other monad resources try to convey? Not particularly.
You are correct. This is an advocacy piece for using Monads to solve common programming problems.
However, I believe this article can still be useful for people who do not yet "get monads". Much of the prose written on Monads never bothers to first address "Why should I care? What problem that I already have can Monads help me solve?"
This shows multiple concrete examples where Monads can improve code clarity and readability. So now you can make an informed decision about whether you want to learn more.
Of course, if you dislike code clarity (and many programmers fall into this category), then Monads may not be right for you.
If this is Java, why not use exceptions, or @NonNull. If this is C++, why not use exceptions?
I'll note that for loops and if statements are fundamental constructs that many people don't really understand. I've seen a lot of bad code written with if statements and for loops. If these fundamental constructs can be misused to create bad code, how much likely is it that more abstract constructs like list comprehensions, futures, and monads will be used to create bad code?
Because each one describes a different type's implementation of the monad interface. The blog post is just trying to illustrate:
"all these problems have the same interface. If we have a general solution to a problem, why use a different ad hoc solution for each?"
var a = getData();
if (a != null) {
var b = getMoreData(a);
if (b != null) {
var c = getMoreData(b);
if (c != null) {
var d = getEvenMoreData(a, c)
if (d != null) {
print(d);
}
}
}
}
do
a <- getData
b <- getMoreData a
c <- getMoreData b
d <- getEvenMoreData a c
print d
Not necessarily. It depends on which monad is being used here (the article doesn't specify). If you replace the 'print' with 'return' to simplify things, then this could be an expression in the Maybe monad, which would return either (Just d) or Nothing.
The article is lying a bit by suggesting that it's trivial to layer short-circuit-on-error behavior on top of the IO monad. It's possible for sure, but some relatively subtle issues can arise (in Haskell at least).
The for loops and if statements were never a problem, it was the default constructors, overloaded operators, and the like that always caused confusion on my teams.
This particular syntax for chaining together monads is called 'do notation', and is just syntax sugar for calling the bind function (flatMap in Java) manually.
If your developers are consistently writing bad code, fire the developers. They will write bad code in any and every language.