Programming language users don’t need to know about Monads. No I won’t get into explaining what a Monad is or isn’t, instead I will focus on the potential usefulness as an angle to this hot topic.
I drafted this post in February 2015 then forgot about it. I recently stumbled upon it again, so I thought to publish it, after some minor editing.
There is a clear chasm in the way people communicate thoughts and concepts within programming language communities. And this chasm manifest itself in the multiple layers of conversations in the communities, interacting at different levels. In the mix, some are discussing language design issues whereas others are just trying to get started with basic concepts.
Let me paraphrase Martin Odersky – I got the following rough definition from him, though I’ve lost the reference, I can’t provide an exact quote, just the idea. I emphasise the main idea:
There are three categories of people in most programming language communities: language designers, framework or toolkit designers, and language users.
These groups of people have different concerns, although they intermingle on social media they seldom speak the same language. This becomes quite obvious when you read their tweets.
Recent years have seen a significant focus on functional programming, the cool kids can’t rave enough about it. These are typically functional programming advocates. Monad, a word that comes up quite frequently in conversations. Wow, it sounds so cool! Nobody wants to be left out, nobody wants to sound old-fashioned or inferior, so everyone think they too should be involved with this monad stuff. I think it’s misguided to just dive in without clear justification. Most regular developers really belong in the language users group, they need not bother about monads too soon.
A regular developer is someone who’s main job is to write software aimed at end users. The work doesn’t result in programming artefacts for other software writers, instead the software is produced for people will just run them. If this is your main job, then you really don’t need to know about monads. If you’re feeling some kind of peer pressure, a sense of being important, if that’s what’s driving you into this monad business, then you are wasting your time.
Having got that away, let me give a really short take on what Monads are useful for, the one definition for the non-initiated (sorry, this is you, software non-librarian):
In essence, Monad is important because it gives us a principled way to wrap context information around a value, then propagate and evolve that context as the value evolves. Hence, it minimises coupling between the values and contexts while the presence of the Monad wrapper informs the reader of the context’s existence.
Excerpts from the book: Programming Scala, by Dean Wampler & Alex Payne. Any typos or mistakes are mine.
This explanation is really good, easy to understand, no PhD in Math required. The word value might be puzzling if your choice of programming language doesn’t have such concept, you could just substitute it with something. Ultimately, this is about writing a more general solution, that can be trusted for soundness and solidity if its architectural concepts are backed by math theories. The notion is popularised by functional programming theories, concepts, programming languages and tools. Monad is one powerful tool from such a trove. The programming language, its libraries and the compiler, combine to provide such power.
The discipline emerged from academia, researchers working on formal proof of algorithm correctness started it all. During my studies at the university, we got introductory lectures on language theories and formal proofs, but never went much too deep. At the time I thought it was really for people who wanted a career in academia, I wanted to make software for people. In recent years, functional programming picked up steam and is ever growing in popularity. I won’t dive further into the background here, there is plenty of material on that.
In the early stages, as your solution is only starting to emerge, it doesn’t make sense to try and reason in terms of monads or not. I think it best to simply write something that works, gives the user what they need. Then only after that first goal is achieved, would you take the time to contemplate what you wrote, look for opportunities to remove boilerplates, repetitions, ambiguities, and so on.
As you engage in this type of exercise, that’s when you start to to think: wouldn’t it be handy if a tool existed, or the compiler, to allow me to make my algorithms and recipes more general, without me having to invent something? That is the point where it is good to look at what your language and its compiler offer, the libraries available. Chances are, you could soon be using some monads without even knowing to call them so.
The more you progress in this journey, the more concise your code becomes, fewer components can perform increasingly more work. The process helps you improve quality, reduce maintenance burden, and even save yourself valuable testing time. If your programming language is built for this, like Scala, Haskell, Idris, OCaml, and so on, then you reap much more rewards. In fact you’d be expected to be building on such concepts. These benefits can be discussed and reasoned about without getting lost in strange cabalistic terminology. Cabalistic is as math may sound like to the uninitiated.
The process illustrated in the previous paragraph would probably be trivial for framework designers. Indeed they need to achieve high levels of reusability without sacrificing performance and legibility. Folks engaged in domain specific language (DSL) design would also have similar aims. Math savvy framework designers would probably go a formal way, that’s where category theory comes into play. Unfortunately, math savvy people can behave like doctors, speaking in tongues that only specialists can understand. And this is how, although well meaning, most people get lost when trying to follow conversations or reasoning involving such concepts.
On social media and blogs, software people who regularly talk about monads and various kinds of math infused concepts, are either language designers, or framework designers, or are perhaps aspiring to become one. They seem to be either demonstrating proficiency, or trying to informally engage people they acknowledge as peers.
That’s it. A programming language user doesn’t need to know about monads. It is useful if they do and can actually take advantage of it, but one can be productive with no knowledge of monads. To those wondering what a monad is, whether they need one or not, I would suggest to check out Dean Wampler’s quote above as a way to assess one’s motivation. If that qualifies their quest, then it is worth reading up many different code samples from multiple languages to find out how to take advantage of it. No need to get mystified.