I appreciate the use of plain english, but it doesn't help understand why these things are good or important. Like, ok, monads avoid double-containering. That's... nice?
I think he specifically addressed people who know Swift's flatMap. I don't, but here's more if you know a little Haskell.
Suppose you have a function of type (String -> IO ()). For example, putStrLn. It takes a String and converts it into a real world computation (printing the string) of type (IO ()).
That's nice, but what if the input string is not purely there but only "hidden" in another IO computation? For example, it could come from getLine which has type (IO String).
Now we have some (IO String) and some (String -> IO ()) and would like to compose these, i.e. print out again what was input. But they are not strictly compatible since the left thing is in IO context (i.e., computed at runtime).
Since IO is a functor we can do (fmap putStrLn getLine) which is of type (IO (IO ())) if you do the math. This is a computation which at runtime computes another computation (putStrLn applied to the computed string).
The thing that Monad gives you is to merge layers. In the case of IO, that is to actually execute the dynamically computed computation. Formally, merging (IO (IO ())) to (IO ()). Or for any type a, merging (IO (IO a)) to (IO a).
The merging method is called join and is the cleanest way to explain what makes a monad. However in haskell the Monad instances are unfortunately given by (>>=) which is a more complicated way to define the same thing. There is also join in Haskell but it's defined in terms of (>>=).
The article is about what they are. Not why they are good or important. Tons of material out there is rambling on about them. Apparently a lot of smart people think they are good and important. But, it's rare that someone explains them clearly without putting on a thesis-defense writing style.
Monads avoiding double-containering is nice because you want to be able to use them a lot without finding yourself working with an Optional<Optional<Optional<Optional<Optional<Optional<Optional<Optional<bool>>>>>>>> at the end.
Applicative computations have effects and return a value. They can be combined but only in a restricted way that ensures that the effects of one of the computations do not depend on the value returned by another.
For example, if you read a person's bio and photo from two independent files and combine them into a Person value, that fits the Applicative model.
However, if the path to the photo file were included in the bio file and not known beforehand, that wouldn't fit the Applicative model, because one of the effects (reading the photo) depends on the result value of the other.
So why have this limitation, and why create a separate interface for it?
- For one, Applicatives are more "analyzable" than unrestricted monadic computations. You can identify the separate stages of a computation, collect estimates of required resources, etc.
- Some effects like concurrency, validation, and context-free language parsing fit the Applicative mold very well.
- Combinations of different Applicative effects are themselves applicative. If you have a computation that reads a file and validates the resulting data (a combination of Applicative effects) the combined effect is Applicative and can be combined with other effects of the same type.
But while I liked that tutorial, I think what worked was time. I tried to write Haskell and slowly got a feel for them. After awhile, I started to read JS and Java code and think "oh, another monad".
