Monads

The Misunderstood "Design Pattern"

Ah, monads—the mere word either sparks intrigue or dread. Monads are often described as magical constructs that solve everything. Well, they don’t. Monads are more like a humble design pattern, focused on readability and problem-solving. While we’ll touch on some theory, think of this as a practical guide, with no magical smoke and mirrors—just one straightforward solution to an everyday problem.

---

What Is a Monad?

To answer this question, let’s first understand the problem it solves. Take the following code as an example:

if (a > b) {
    if (c < d) {
        if (e != f) {
            ...
        }
    }
}

One can immediately see that the code is deeply nested and difficult to comprehend. Keen readers might argue this could be solved with early returns. True in some cases, but not entirely, because:

• The deep nesting problem isn’t limited to if blocks alone.

• Even with early returns, the code might become long and difficult to follow.

• Above all, we may not want to return right away; we might want to do something else, like adding an error message to an array.

In the above example, the unit of operation is comparison. Similarly, the unit of operation in a loop is iteration, and in async/await, it’s an external call. From this, a monad can be practically defined as a pattern/construct/container/wrapper that encapsulates a unit of operation and chains subsequent operations in a flattened way.

The above example can be rewritten as below: where If and AndIf are extension methods

If( _ => a > b)
.AndIf(_ => c < d)
.AndIf(_ => e != f);

This is an over-simplified example, and that’s intentional, as many other posts about monads dive into complex details, leading readers to misunderstand what they really are.

Similarly, nested for loops can be simplified as below:

From:

foreach (var outerItem in outerCollection)
{
    foreach (var innerItem in outerItem.innerCollection)
    {
         ...
    }
}

To:

outerCollection.SelectMany(innerItem => ...);

---

TypeScript Example

In TypeScript, here’s an example with nested callbacks and the async/await equivalent:

// Using nested callbacks
function getUserInfoWithCallback() {
    fetchUserData((user) => {
        fetchUserProfile(user.id, (profile) => {
            console.log("User data:", user);
            console.log("User profile:", profile);
            // More nested operations could go here
        });
    });
}

// Using async/await
async function getUserInfoMonadic() {
    const user = await fetchUserData();
    const profile = await fetchUserProfile(user.id);
    console.log("User data:", user);
    console.log("User profile:", profile);
}

---

Am I a Functional Programmer?

Absolutely not (well, maybe—actually, I don’t know). Contrary to popular belief, monads aren’t exclusive to functional languages. Languages like C# and JavaScript are more than happy to sneak them in under different names (looking at you, async/await). If you’ve ever been caught in callback hell or wrangled with nested foreach loops, you’ve already encountered the kinds of issues that monads can help clean up.

Pro tip: You can stop feeling guilty about using monads outside of functional programming—it’s not cheating; it’s efficient coding.

Let’s defer the usual definition until the end because, let’s be honest, the only thing scarier than “Category Theory” is the phrase “Category Theory for Beginners.” In essence, monads help manage data transformations in a readable and declarative way. They structure your code around sequences of operations, ensuring each step flows neatly into the next without trapping readers in a labyrinth of early returns and conditionals.

Think of monads as tidy helpers for your code, ensuring the solution feels more like a conversation than an interrogation.

---

Composing Operations with Monads

Monads provide a way to compose multiple operations in a clear, organized sequence. For example, if you’re validating data, monads can help you set up a chain where each validation runs only if the previous one succeeded, saving you from a jungle of nested statements.

Example in C#:

var result = email.Validate()
.Then(_ => password.Validate())
.Then(_ => username.Validate())
.Map((e, p, u) => new(e, p, u));

This code is declarative and easy to read. Each validation step is composed neatly, without excessive conditionals or manual error handling. For this to work, email, password, and username should adhere to a common interface, say IValidated or IValidatable, and Validate() should return the same type. For the adventurous C# programmer, you can add Select and SelectMany methods to these types so that LINQ query syntax can be used, like so:

from validatedEmail in email.Validate()
from validatedPassword in password.Validate()
from validatedUsername in username.Validate()
select new UserRegistration(validatedEmail, validatedPassword, validatedUsername);

Fear not—many languages have their own way of expressing monad continuations. Just as with design patterns, understanding monads is less about memorizing their structure and more about recognizing when they solve a particular problem.

---

The Hyped-Up Monad Problem

Here’s the kicker: a lot of literature makes monads sound like mystical constructs with powers beyond mortal comprehension. This over-glorification can set readers up for disappointment. Yes, monads are useful, but they’re not an arcane force that transforms code into pure gold. They’re a design pattern—like the Singleton or Factory patterns—but with an actual definition.

Fun fact: The term “design pattern” is often code for “not exactly defined, but sounds good.” At least monads have actual definitions!

---

Monads, Category Theory, and Why We Should (Mostly) Ignore It

Yes, monads come from category theory, and understanding that foundation is great for abstraction. But for the everyday developer, thinking of monads as design patterns for readability is often more practical. Sure, learning category theory can make pseudocode nearly identical to real code across languages, but nobody’s handing out gold stars for that. Here’s the theoretical definition:

A monad is defined as a triple (T,η,μ)(T, \eta, \mu)(T,η,μ), where:

• TTT is a functor that maps objects and morphisms between categories.

• η\etaη (unit) wraps a value in the monadic context, like Just x for Maybe.

• μ\muμ (bind) flattens nested monads, ensuring operations combine smoothly.

Monad Laws (Ignore if You’re Sane)

For those interested, monads must satisfy three laws to chain operations reliably:

• Left Identity: return x >>= f is the same as f x

• Right Identity: m >>= return is the same as m

• Associativity: (m >>= f) >>= g is the same as m >>= (\x -> f x >>= g)

---

Final Thoughts

Monads are best thought of as a design pattern for readability, not a complex mathematical structure only for the elite. In essence, monads help you nested code to be flattened and chained. There are some advanced theory behind how these can also be used to isolate side-effects from the business logic. We did not deal with that in this post though. By keeping things grounded and applying monads where they naturally fit, we can avoid the hype and find practical solutions. And remember: if you ever feel the urge to start with “In category theory…”—just don’t.