Skip to content

Instantly share code, notes, and snippets.

@joost-de-vries
Last active August 29, 2015 14:12
Show Gist options
  • Save joost-de-vries/4d0a6e622545ffa3a74c to your computer and use it in GitHub Desktop.
Save joost-de-vries/4d0a6e622545ffa3a74c to your computer and use it in GitHub Desktop.
The M word

A lot of explanations of monads start from a mathematical terminology. Which is unnecesarily obscure if you just want understand why they're handy in programming.

If you have a background in OO you can see Monad as an interface. Similarly Monoid can also be viewed as an interface. Gilad Bracha said that something that supports a function like mappend should really be called Addable (instead of Semi-group). Because that's what we can do with it. And if it also supports a function like mempty it should be called Foldable (instead of Monoid); because it provides the two arguments that a fold function requires.

Following the same naming convention the name Chainable would be more intuïtive than Monad. Because the reason that we value bind (or flatMap) so much is that we can chain (or 'compose) smaller parts into bigger parts and automatically handle alternate flows or side effects.

Because that's why Chainables (or Monads) are a big deal: we can build bigger things from flatmap invocations; you can chain (or: 'compose') them. And using a chain of flatmaps allows you to only focus on the happy path instead of some other case, like f.i. the case that one of your functions returns an exception, or null. In Groovy they have something called the Elvis operator which allows you to focus on the non-null happy path. Flatmappables (or: Monads) provide a general mechanism that's not just for null values.

In the paragraph above I've used a lot of quotes from Erik Meijer that I've found particularly useful in understanding this subject (monad is an interface, category theory is OO interfaces for mathematicians, monads allow you to focus on the happy path when it comes to side effects like exceptions, latency etc). I don't know why he did not use these explanations again in this course.

All of this is just my attempt at trying to encourage you; how you can use monads is really not that hard. It just needs getting used to and you need to ignore the mathematical noise.

(Btw I have now offended against the general indictment against providing another monad explanation. See f.i. https://www.haskell.org/haskellwiki/Monad_tutorials_timeline)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment