It is, after all, just a monoid in the category of endofunctors.

Thanks, it all clicked now.

This is a famous quote from the first real book on category theory. "Categories for the Working Mathematician" by Saunders Mac Lane.

I think this is the mistake a lot of people make: they form an intuition of monads after seeing lots of examples of them, and then they try to communicate that intuition without just saying "here are lots of examples of monads".

That could be it. Perhaps my lack of understanding of category theory means I've only developed the pattern recognition for monads but not a deep understanding. So I can only explain it as the abstract thing all of these things have.

I am gonna be heavily opinionated, take my words with a bit of salt ;)

Here it goes:

1. One understood monads when one is able to write a monadic interface that behaves like any intermediate haskell would expect it to behave. This is not a hard task.

2. Screw the abstract stuff. While fascinating, really few people understand concepts going from abstract to concrete rather than the other way around. And don't get me wrong, I don't think these kind of people are better theorists or problem solvers, they just have to seem a special relationship with symbols. If you are one of those people, you would likely know - in any case, I would encourage to write 3-5 examples of monads in Haskell or Java or JavaScript or whatever language suits you and go from there.

To me, it is because the term 'a monad' refers to a thing that doesn't even exist as its own thing in programming. Of course your can realize a monad, but the monad is not the type, nor the function, but the abstract, mathematical "thing" that defines a type and the two operations (value wrapping, and the compose function).

Programmers without a mathematical background will naturally struggle with such concepts. You can't point to where in the the code "the monad" is, as it's just the pattern, or the abstract mathematical combination of the type and the operations. Sure you could pack them into a class or a module, but it's still hard to point to where "the monad" is.

When we describe other patterns, like a Singleton, Factory, an Adapter, etc., it's is much more clear what and where the thing is. It's just a word to describe a function, a class, or a module.

Perhaps 'function composition with metainformation' would be a better title for the pattern. You take composable functions that act on certain types, and extend them to support metainformation attached to the values, while defining how the metainformation combines.

This is a pretty good explanation but it's missing one detail: the laws.

A monad is an applicative functor which is a functor. Each of these concepts in the hierarchy comes with a set of laws which must be obeyed. For example, all functors (which define an operation, fmap) must obey 2 laws:

Identity

fmap id == id

Composition

fmap (f . g) == fmap f . fmap g

All instances of Functor must obey these laws. Furthermore, since every Monad is also a Functor, all instances of Monad also obey these laws (in addition to extra laws).

Yeah, I haven't done any Haskell but from what I understand "a monad" is just a type that lets you call `.map()` on it and do the normal thing that `map()` does. Would it be wrong to call it `mappable`? That would be a much clearer name.

What you are describing is a Functor, one the two other important Haskell "design-patterns" (Functor - Applicative - Monad). "Mappable" is a good name insofar as it is more familiar to new folks. However, I like the mathematical name as it forces one to embrace the interface as what it is, as opposed to thinking about Functors as collection of data that can be mapped over. Often this is true, but not always.

A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up.

> one the two other important Haskell "design-patterns" (Functor - Applicative - Monad)

These days you should probably add Foldable and Traversable to that list, as they are closely related and appear throughout the standard libraries and even in the Prelude.

Traversable is a generalization of Functor to include Applicative effects. It reduces to Functor if the Applicative happens to be the Identity type.

Where Functor and Traversable replace values one-to-one while preserving structure, Foldable represents reducing operations (folds) which consume the values from a structure in some defined order to build up a result. This includes basic functions like sums and products, as well as more complex operations like `sequence`.

> A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up.

Hmm well it might break down but simply by choosing a better word you've helped me understand what a monad is more than any article I've read on the matter.

It's not that. The thing you're describing is often called a "functor". It could be called a "mappable" but generally once you've heard a functor is a thing that has a .map() function that works the way you expect it to then you don't really need to call it a mappable anymore. So the name sticks.

Even to just be able to rapidly identify why having a thing that .map()s is a meaningful object represents the sort of experience with and abstraction of these concepts that'll put you ahead of the game for understanding monads.

Oh yeah I mixed them up. I still think `Mappable` is a much better name than `Functor`, and names matter. Especially for difficult to understand concepts. Functor isn't really even the right type of word. It should be Functable or something.

Monad should be `FlatMappable`. I found this great article where they use exactly these terms to explain it:

https://dev.to/joelnet/functional-javascript---functors-mona...

If people are using different terms to explain your confusing terminology then... maybe the confusing terminology is not very good.

Names certainly do matter: they're how we effectively communicate with each other. If you call it a mappable, and someone else calls it a chainable (as was said elsewhere in this comment thread), how have we eased confusion? If I try to google what a chainable is, what will I find?

On the other hand, if I say "it's a monad" then people who have encountered the term before know what I mean (even if they've had no need to understand monads in depth) and people who have not will successfully find information about the right thing if they search for it.

Monads have a particularly bad reputation for being hard to learn, despite appearing in non-general form in every modern language. Since people seem to have little trouble grasping the way in which futures, streams, and options work I don't think there's really such a great challenge involved - but the culture of running screaming from the mere word doesn't help matters in the least.

I'm not saying functor is a good name. I'm saying it's the name that's more or less stuck. To start using a new one is just to make the terminology even more confusing.

For what it's worth, "functor" properly describes the combination of a type and its relevant .map() function. It's (common) shorthand to refer to just the type as "a functor" when there's a unique, well-known functor that utilizes that type.

So, we could be more precise, of course. But also if you just throw up your hands when someone says "a list is a functor" then you're fighting a difficult battle.

"Functor" is a perfectly good and descriptive name… provided you are at least somewhat familiar with the esoteric branch of mathematics it's based on. For someone from a Category Theory background renaming it to "Mappable" would be weird and unintuitive. And as in most things, those actually doing the work get to pick the names that make sense to them.

If you're not even slightly familiar with that branch of mathematics it's still a perfectly good and descriptive name, because you can search for the term and get loads of relevant information from the programming side of things.

(The mathematical basis helping you get deeper insights into it is just a bonus, albeit IMO a valuable one.)

I disagree: there are often different ways to implement a design pattern, so IMHO a design pattern is an abstract idea in the same way monads are.

The main difference is that design patterns have 'fuzzy' rules whereas monads are more precisely defined.

I think one problem is that there is the mathematical concept of monad and the programming pattern monad. On abstract level they are the same, but in practice and for illustrative purposes they are not.

I think it's because it's a concept that constrains how multiple instances of a type interact, and we're used to thinking of types as putting restrictions on single instances.

Why is it that I can't play musical instruments after someone has explained to me in simple English what musical instruments are?

https://two-wrongs.com/the-what-are-monads-fallacy

Imagine if functions were explained the same way: A function is just a mapping from a domain to a codomain. This would also be pretty useless and confusing for someone trying to lean how to write print("hello world")

Could you explain it to me?

In a typical imperative programming language, there's an "environment" that the actual lines of your program operate within. You can think of the environment as all of the sources your program can consume data from (files, databases, system clock, random number generator, keyboard, etc) and all of the sinks your program can write data into (files, databases, logs, the screen, etc).

Monads are an approach to modeling the idea of running a set of statements in a particular environment, with specific input and/or output capabilities, often called "effects".

In your typical programming language, you've only got one type of monad, which is the language runtime. You can do literally any type of effect at any time. That is very powerful, but it also makes programs difficult to reason about.

In many typed functional programming languages, monads are used to create much more specific contexts for running sequences of computations and effects. That makes reasoning about local sections of your program way easier.

One might think "why would I want to limit my power?" And the answer is you're only limiting yourself locally. It's exactly the same as how procedural programming dispensed with the all powerful GOTO, but it turned out that breaking programs into functions made them much easier to reason about.

And it turns out that once you start thinking that way, you can often offload some pretty tricky logic into a well designed monad.

A major caveat is that things can get pretty complex when you try to compose monads, and for me, that's where the love affair ended. There are alternative models for how to constrain effects, like algebraic effect systems, which try to be more intuitive and composable.

This describes some monads but not others. IO and State can be thought of as environments supporting effects, but it doesn't really make sense to think of a List like that.

The problem with many monad explanations is they only explain particular monads but then other monads become even more confusing.

I've heard the List monad described as modeling nondeterminism as an effect. As you chain flatMaps, at each stage, you're consuming a discrete set of possible inputs and producing a new set of potential outputs per input.

So it's a little different from thinking of your program as something that is once. Instead, you have your program being run multiple times, with the environment injecting different at each stage.

I think the Future/Promise monad is similar. The environment is taking responsibility for pausing and resuming computation.

But I'm curious if you have other monads in mind where the analogy fails.

A ordinary list expression like [x + 2 | x <- [7, 9, 13]] is not effectful or non-deterministic. It is completely deterministic and have no side effects.

Correct that there's no literal effect, but conceptually, if you wanted to model a particular sort of nondeterminism as a monad, you could use one indistinguishable from List.

And I think it holds just fine to think of the monad as injecting data into a sequential computation before each step and ingesting output after each step (boxed in the monadic container).

Which reminds me, that boxing is also part of the power of monads. It means you can nest steps of a monadic computation, instead of just chaining them, as a functor allows. This stimulates lexical scope -- bindings that exist for all statements after the one that defines them.

Not really. Here is one of the articles that helped me click. https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/...

After trying to understand it at a more fundamental level I have a suspicion that that piggy wiggies are involved.https://www.google.com/amp/s/bartoszmilewski.com/2014/10/28/...

A monad is for composing effectful computations.

Effects are encoded using a polymorphic type with a `map` operation (called a functor), and effectful computations are functions `a -> E b` for some types `a, b` and effect `E`.

A monad is exactly the plumbing you need for composing effectful computations: it turns a computation `b -> E c` into a `E b -> E c` so that you can compose `a -> E b` with `E b -> E c` to get a composed computation `a -> E c`.

It does so in a way that makes effectful composition associative (i.e. the way you'd expect)

Is Maybe/Option an effectful computation? Is List? I don't think it's really accurate to say this is what monads are "for". It's one use for monads but monads aren't "for" anything and there are monads that are not about effects.

"Effect" is perhaps a broader notion than one might think: it's an effect to write to a file or mutate some variable, sure, but it's also an effect to raise an exception, goto a label, raise an exception, execute asynchronously, be one of a set of possible outcomes, and plenty of other notions.

There's a name for the monad in which there is no effect: the identity monad.

The heart of a monad is the bind/flatMap/and_then interface, in which the value contained in the monad is computed on to produce a new monadic value. This is where the effect occurs: something other than just running the function happens.

If the bind implementation only runs the provided function then there's no effect, and it's the identity monad.

> Is Maybe/Option an effectful computation

Yes, Maybe/Options are a way of encoding partial functions/exceptions.

List is a way of encoding non-determinism.

Operations on a list (like map, filter) are not effectful computations.

The problem with many monad explanations is they explain only particular monads. IO and State can be thought of as effectful computations, but List operations cannot.

Monads are just a pattern for composing computations, it doesn't say anything about the semantics of those computations.

> but List operations cannot.

They can, the effect modeled by the list monad is non-determinism.

I recently wrote an explanation aimed at Scala developers, so if the syntax is not an obstacle this may help: https://upsolver.engineering/posts/monads-are-not-that-compl...

In short: Functors (a tightly related concept) are about types that have ‘.map()’, and Monads are Functors that in addition have ‘.flatMap()’.

I offer a simple explanation elsewhere in this thread: https://news.ycombinator.com/item?id=31652379

There's a great FP podcast, the lambdacast. They aren't making new episodes, but if you listen in order, by the time you get to the monad episode it all makes sense n

A monad is just an object.

I'm pretty sure a monad is just an endoid in the category of monofunctors?