"A monad is just a monoid in the category of endofunctors".

I've long fired (harsh) criticism at the FP community for statements like this, because to the outside world, it seems like a bunch of esoteric nonsense words thrown around condescendingly just to sound smart.

But...

As I've learned about more about FP & monads, I've now (to some extent anyway) learned more what those words mean. I can actually explain them, a bit.

But before I do, let me re-frame this statement, not as condescension but as a genuine attempt to draw other angles of insight.

IOW, the statement is not intended for those who are LEARNING monads, but for those who are already deeply steeped in it, and are looking for additional "connections" between distinct, **already-known** concepts.

In regular arithmetic, say you have an epiphany and then tell a friend:

"Division (n = x / y) is just repeated subtraction (x - (n * y))."

That statement is true, but it doesn't necessarily present the topic in a way that's conceptually optimal to TEACH division initially.

Instead, that sort of "x is just y" statement is intended for someone *who already knows division*, but is eager to understand it more deeply by restating its definition in terms of other known concepts. This is a key step in deeper learning, but it's rarely an *early* step.

So, "...just a monoid in the category of endofunctors" shouldn't be shared in the context of initially explaining/teaching monads, because it's not *FOR* those who don't already understand monads, monoids, and endofunctors.

Doing so DOES come across as condescending nonsense.

I wish I had appreciated the importance of, as well as the appropriate audience for, that "...just a monoid..." statement.

I wouldn't have made fun of it so often. I wouldn't have propagated the "us vs them" separation, the elitism of "special, deeper insight".

I would have instead said, "Don't fear this statement, because it has some truth you may someday understand, but don't concern yourself with those confusions right now."

I really wish I had understood that before now.

So, what do those words in that statement mean?

A monoid is a semigroup (concatable) plus an empty/identity value. For example, strings, because you can concatenate two strings, and you can also concatenate with an empty "" and not change the value.

Functor is the ability to map over a (set of) value(s). For example, arrays are functors because we can map(..) from one array to another array, having applied a function to each of its values.

Even if a monad (or array!) just holds a single value, map() creates a new container.

Functor is actually broader than that definition implies: you *could* start with something like an array and map to something else entirely (something not an array).

That probably seems weird, because we wouldn't commonly do that.

For our general purposes, and for monads in particular, that wouldn't be true. If you map from an array, you'd get back an array.

Endofunctor is the term for that narrower kind of functors where the source category and the result category are the same (array -> array).

So:

A concatable set of values (like strings or arrays) that additionally includes an empty/identity value, which can be mapped to another set of values of that same kind...

That's *a* way of describing what a monad is. Not where I'd START teaching monads, but still valid/true.

Where *would* I start in explaining what a monad is?

(bracing for criticisms)

It's a value (or set of values) plus some behavior to do stuff with the values, with rules about how that collection will interact with others.

If you squint, you *could* call that a data structure.

A lot of FPrs will be upset at me calling it a data structure. That's not a broad enough concept for all monads. A monad is an "algebraic structure" and much more flexible than "data structure" makes it seem.

Nevertheless, "data structure" seems to me like a good place to start.