The Monad Called Free (2014) • Hacker News Board

Re: The Monad Called Free (2014)

#21

Post by anon291 » Fri, Feb 06, 2026, 8:42 PM UTC

lisper wrote: post #14

kmeisthax wrote: post #12

Earlier quoted context omitted.

It's also important to note that in Haskell and other functional programming languages, there is no implied order of operations. You need a Monad type in order to express that certain things are supposed to happen after other things. Monads can also express that certain things happen "in between" two operations, which is why we have different kinds of Monads and mathematical axioms of what they're all supposed to do.…

> You need a Monad type in order to express that certain things are supposed to happen after other things This is the kind of explanation that drives me absolutely batshit crazy because it is fundamentally at odds with: > Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. So, I think I understand flatmap, assuming that this is what you mean: https://www.w3schools.com/Jsref/jsref_array…

Because you're not used to abstract algebra. JavaScript arrays form a monad with flatmap as the join operator. There are multiple ways to make a monad with list like structures.

And you are correct. Monads have nothing to do with sequencing (I mean any more than any other non commutative operator -- remember x^2 is not the same as 2^x)

Haskell handles sequencing by reducing to weak head normal form which is controlled by case matching. There is no connection to monads in general. The IO monad uses case matching in its implementation of flatmap to achieve a sensible ordering.

As for JavaScript flat map, a.flatMap(b).flatMap(c) is the same as a.flatMap(function (x) { return b(x).flatMap(c);}).

This is the same as promises: a.then(b).then(c) is the same as a.then(function (x) { return b(x).then(c)}).

Literally everything for which this is true forms a monad and the monad laws apply.

Re: The Monad Called Free (2014)

#22

Post by anon291 » Fri, Feb 06, 2026, 8:44 PM UTC

wat10000 wrote: post #16

KPGv2 wrote: post #7

Earlier quoted context omitted.

Right. I don't know how many times I've been exasperated by how monads are perceived as difficult. Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Technically it's also an applicative functor, but at the end of the day, that gives us a few trivial things: - a constructor (i.e., a way to put something inside your monad, exactly how `[1]` constructs a list out of a natural number) -…

> Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Awesome! Now I understand. > Technically it's also an applicative functor Aaaand you've lost me. This is probably why people think monads are difficult. The explanations keep involving these unfamiliar terms and act like we need to already know them to understand monads. You say it's just a flatmappable, but then it's also this othe…

I mean people need to be familiar with mathematics. In mathematics things form things without having to understand them.

For example, The natural numbers form a ring and field over normal addition and multiplication , but you don't need to know ring theory to add numbers..

People need to stop worrying about not understanding things. No one understands everything.

Re: The Monad Called Free (2014)

#23

Post by platinumrad » Fri, Feb 06, 2026, 8:52 PM UTC

anon291 wrote: post #19

KPGv2 wrote: post #7

Earlier quoted context omitted.

Right. I don't know how many times I've been exasperated by how monads are perceived as difficult. Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Technically it's also an applicative functor, but at the end of the day, that gives us a few trivial things: - a constructor (i.e., a way to put something inside your monad, exactly how `[1]` constructs a list out of a natural number) -…

Forget programming, everyday business and physics is monadic in function. And if-then statements are functorial. These are very general thought patterns.

These are vacuous statements.

Re: The Monad Called Free (2014)

#24

Post by Nevermark » Fri, Feb 06, 2026, 9:06 PM UTC

nine_k wrote: post #17

wat10000 wrote: post #16

Earlier quoted context omitted.

> Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Awesome! Now I understand. > Technically it's also an applicative functor Aaaand you've lost me. This is probably why people think monads are difficult. The explanations keep involving these unfamiliar terms and act like we need to already know them to understand monads. You say it's just a flatmappable, but then it's also this othe…

But words like "incapsulation" or "polymorphism" or even "autoincrement" also sound unfamiliar and scary to a young kid who encounters them the first time. But the kid learns their meaning along the way, in a desire to build their own a game, or something. The feeling that one already knows a lot, sort of enough, and it'd be painful and boring to learn another abstract thing is a grown-up problem :-\

Those words need definitions, but they can both be defined using words most people know.

Casual attempts at defining Monads often just sweep a pile of confusion around a room for a while, until everything gets hidden behind whatever odd piece of furniture that is familiar to the person generating the definition. They then imagine they have cleared up the confusion, but it is still there.

Re: The Monad Called Free (2014)

#25

Post by secretballot » Fri, Feb 06, 2026, 9:07 PM UTC

anon291 wrote: post #19

KPGv2 wrote: post #7

Earlier quoted context omitted.

Right. I don't know how many times I've been exasperated by how monads are perceived as difficult. Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Technically it's also an applicative functor, but at the end of the day, that gives us a few trivial things: - a constructor (i.e., a way to put something inside your monad, exactly how `[1]` constructs a list out of a natural number) -…

Forget programming, everyday business and physics is monadic in function. And if-then statements are functorial. These are very general thought patterns.

> everyday business and physics is monadic in function.

So?

> And if-then statements are functorial.

So?

All the "this is hard" stuff around these ideas seems to focus on managing to explain what these things are but I found that to progress at the speed of reading (so, about as easy as anything can be) once it occurred to me to find explanations that used examples in languages I was familiar with, instead of Haskell or Haskell-inspired pseudocode.

What I came out the other side of this with was: OK, I see what these are (that's incredibly simple, it turns out) and I even see how these ideas would be useful in Haskell and some similar languages, because they solve problems with and help one communicate about problems particular to those languages. I do not see why it matters for... anything else, unless I were to go out of my way to find reasons to apply these ideas (and why would I do that? And no, I don't find "to make your code more purely-functional" a compelling reason, I'm entirely fine with code I touch only selectively, sometimes engaging with or in any of that sort of thing).

The "so?" is the part I found (and find) hard.

Re: The Monad Called Free (2014)

#26

Post by wat10000 » Fri, Feb 06, 2026, 9:24 PM UTC

anon291 wrote: post #22

wat10000 wrote: post #16

Earlier quoted context omitted.

> Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Awesome! Now I understand. > Technically it's also an applicative functor Aaaand you've lost me. This is probably why people think monads are difficult. The explanations keep involving these unfamiliar terms and act like we need to already know them to understand monads. You say it's just a flatmappable, but then it's also this othe…

I mean people need to be familiar with mathematics. In mathematics things form things without having to understand them. For example, The natural numbers form a ring and field over normal addition and multiplication , but you don't need to know ring theory to add numbers.. People need to stop worrying about not understanding things. No one understands everything.

Now imagine if every single explanation of natural numbers talked about rings and fields. Nobody ever just says "they're the counting numbers starting from one." A few of them might say, "they're the counting numbers starting from one, and they form a ring and field over addition and multiplication." And I might think, I understand the first part, but I'm not sure what the second part is and it sounds important, so maybe I still don't know what natural numbers are.

I'm not worried, but it's amusing to see this person say it's so simple, and then immediately trample on it.

Re: The Monad Called Free (2014)

#27

Post by nine_k » Fri, Feb 06, 2026, 10:20 PM UTC

Nevermark wrote: post #24

nine_k wrote: post #17

Earlier quoted context omitted.

But words like "incapsulation" or "polymorphism" or even "autoincrement" also sound unfamiliar and scary to a young kid who encounters them the first time. But the kid learns their meaning along the way, in a desire to build their own a game, or something. The feeling that one already knows a lot, sort of enough, and it'd be painful and boring to learn another abstract thing is a grown-up problem :-\

Those words need definitions, but they can both be defined using words most people know. Casual attempts at defining Monads often just sweep a pile of confusion around a room for a while, until everything gets hidden behind whatever odd piece of furniture that is familiar to the person generating the definition. They then imagine they have cleared up the confusion, but it is still there.

Most engineers don't have too much trouble understanding things like List, or Promise, or even Optional, which all demonstrate vividly what a monad does (except Promise in JS that auto-flattens).

A monad is a generalization of all them. It's a structure that covers values of type T, some "payload" (maybe one, like Promise, maybe many, like List, maybe even none, like List or Optional sometimes). You can ask it to do some operations on these values "inside", it's the map() operation. You can ask it to do similar thing when operation on each value produces a nested structure of the same kind, and flatten them into one level again: this is flatMap(). This is how Promises are chained. The result is again a structure of the same kind, maybe with "payload" of a different type.

This is a really simple abstraction, simpler than most GoF patterns, to my mind, and more fundamental and useful.

Re: The Monad Called Free (2014)

#28

Post by skybrian » Fri, Feb 06, 2026, 10:25 PM UTC

hutao wrote: post #11

skybrian wrote: post #9

I keep bouncing off this stuff due to the lack of concrete examples where it would be useful. Maybe some documentation organized like the Design Patterns book would be helpful?

A great way to understand monads is as a "design pattern," because they pop up extremely often in practical programming. Consider functions with a type signature that looks like `A -> T `, such as `A -> Promise ` or `A -> Optional `. If you have some function fetchResponse that returns a Promise , and a function processJSON that takes a Response as an argument, you cannot compose them the usual way, as `processJSON(f…

This explanation doesn't contain any practical examples either. I mean, I do know that Promises are a monad, but that's not obviously helpful. You can write plenty of async code using Promises without knowing that, and it will probably be clearer to the reader. Similarly, options are a monad, but that's unhelpful for writing code that deals with optional values.

Why is most writing about functional programming like this?

Re: The Monad Called Free (2014)

#29

Post by a57721 » Fri, Feb 06, 2026, 10:26 PM UTC

anon291 wrote: post #22

wat10000 wrote: post #16

Earlier quoted context omitted.

> Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Awesome! Now I understand. > Technically it's also an applicative functor Aaaand you've lost me. This is probably why people think monads are difficult. The explanations keep involving these unfamiliar terms and act like we need to already know them to understand monads. You say it's just a flatmappable, but then it's also this othe…

I mean people need to be familiar with mathematics. In mathematics things form things without having to understand them. For example, The natural numbers form a ring and field over normal addition and multiplication , but you don't need to know ring theory to add numbers.. People need to stop worrying about not understanding things. No one understands everything.

I get your point, but the natural numbers do not form a ring or field.

Re: The Monad Called Free (2014)

#30

Post by WorldMaker » Fri, Feb 06, 2026, 10:34 PM UTC

kmeisthax wrote: post #12

KPGv2 wrote: post #7

Earlier quoted context omitted.

Right. I don't know how many times I've been exasperated by how monads are perceived as difficult. Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Technically it's also an applicative functor, but at the end of the day, that gives us a few trivial things: - a constructor (i.e., a way to put something inside your monad, exactly how `[1]` constructs a list out of a natural number) -…

It's also important to note that in Haskell and other functional programming languages, there is no implied order of operations. You need a Monad type in order to express that certain things are supposed to happen after other things. Monads can also express that certain things happen "in between" two operations, which is why we have different kinds of Monads and mathematical axioms of what they're all supposed to do.…

> Maybe/Either get talked about because they're the simplest Monads you can make, but it makes Monads sound like a spicy container type.

Actually "spicy container type" is maybe a better definition of Monad than you may think. There's a weird sort of learning curve for Monads where the initial reaction is "it's just a spicy container type", you learn a bit and get to "it is not just a spicy container type", then eventually you learn a lot more and get to "sure fine, it's just a spicy container type, but I was wrong about what 'container' even means" and then settle back down to "it's a spicy container type, lol".

"It's a spicy container type" and "it's anything that is flatmappable" are two very related simplifications, if "container" is a good word for "a thing that is flatmappable". It's a terrible tautological definition, but it's actually not as bad of a definition as it sounds. (Naming things is hard, especially when you get way out into mathematical abstractions land.)

There are flatmappable things that don't have anything to do with ordering or sequencing. Maybe is a decent example: you only have a current state, you have no idea what the past states were or what order they were in.

Flatmappable things are generally (but not always) non-commutative: if you flatmap A into B you get a different thing than if you flatmap B into A. That can represent sequencing. With a Promise `A.then(() => B)` is different sequence than `B.then(() => A)`. But that's as much "domain specific" to the Promise Monad and what its flatmap operation is (which we commonly call `then` to make it a bit more obvious what its flatmap operation does, it sequences; A then B) than anything fundamental to a Monad. The fundamental part is that it has a flatmap operator (or bind or then or SelectMany or many other language or domain-specific names), not anything to do with what that flatmap operator does (how it is implemented).