Monads, part one | Fabulous Adventures In Coding

Lots of other bloggers have attempted this, but what the heck, I'll give it a shot too. In this series I'm going to attempt to answer the question:

I'm a C# programmer with no "functional programming" background whatsoever. What is this "monad" thing I keep hearing about, and what use is it to me?

Bloggers often attempt to tackle this problem by jumping straight into the functional programming usage of the term, and start talking about "bind" and "unit" operations, and higher-order functional programming with higher-order types. Even worse is to go all the way back to the category theory underpinning monads and start talking about "monoids in the category endofunctors" and the like. I want to start from a much more pragmatic, object-oriented, C#-type-system focussed place and move towards the rarefied heights of functional programming as we go.

Object-oriented programmers like talking about "design patterns", so let's use that as our framing device.

The idea of "design patterns" comes from real-world-let's-build-a-building architecture. You see the same patterns come up over and over again in architecture in the several millennia that humans have been building stuff: walls, doors, windows, ceilings, columns, vestibutes, courtyards, drawbridges, moats, closets, kitchens and so on. These things all have relationships to each other; a courtyard with no doors and windows is not a very useful courtyard. And these patterns and their relationships are pretty stable over time and space; the Pentagon and a 1900-year old Roman-style villa clearly have many patterns in common despite the vast gulf of time and space between their constructions.

So too with software, we see the same recognizable patterns come up over and over again: functions, variables, types, and so on. Those patterns are so ingrained into our languages, so a part of the air we breathe that we seldom even notice that they are design patterns, but they are. And therefore when we discuss design patterns it is almost always in the context of a pattern that is not a part of the language, but rather must be explicitly implemented by the developer.

C#, for example, does not have the "singleton" pattern (that I mentioned last time) "baked in" to the language. It could have been; there could be special syntax for singleton class C { ... }, as there is for static classes or abstract classes. The C# language designers did not consider it an important enough pattern to be elevated into the language as a first class feature, so you've got to "follow the pattern" yourself if you want to make a singleton.

The "monad pattern" is just another design pattern for types, just as the singleton pattern is a design pattern for types. It's a description of the "shape" of a solution to a number of problems. The thing about the monad pattern is that, unlike the singleton pattern, it can sneak up on you. Plenty of developers have used the monad pattern entirely by accident, not realizing that they're re-inventing something that already has a name.

Man, things are starting to get highfalutin already and that is specifically what I want to avoid. Next time on FAICwe'll take a look at some examples of types that have the monad flavour to them and see what they have in common.

Photos of the trifolium villa at Dougga and the Pentagon are from Wikimedia Commons; click on the photos for larger versions and for the photo credits.