
A monad is a monoid in the category of endofunctors, what’s the problem? - joe_poole
https://www.reddit.com/r/math/comments/ap25mr/a_monad_is_a_monoid_in_the_category_of/
======
joppy
Knowing that a ring (in abstract algebra) is equivalently defined as "a monoid
object in the category of abelian groups" is not going to help you with your
first abstract algebra course. It makes things that are glaringly obvious from
the usual perspective totally opaque, and means you have to define things like
the tensor product of abelian groups properly before you can even define a
ring. I don't know of a professor who would even mention this perspective
during a first abstract algebra course. You get much a much better intuition
for what rings are by just using them.

Mathematicians who work in category theory have often seen many, many examples
of algebraic structures before they get abstracted away to "a monoid object in
the category of blah", and many mathematicians still find it an exercise to
unpack these compact definitions back to something more intuitive, or more
familiar. And even so, most of the time identifying your favourite object as
some abstract category thing doesn't bring anything new or useful to the table
for the study of that object. (It can help spot patterns between objects
though).

I say this for any aspiring Haskell programmers: don't feel like understanding
this statement will make you a better programmer. The best way to get better
at using monads is to just use monads more, and play around with them.
Tracking down all the definitions in the statement is a neat exercise, though.

~~~
nerdponx
On the flipside, knowing that a ring is "like a group (which we already
covered), with another operation that follows these axioms" is useful, and
still mostly rigorous.

It's better than "eh just use it a lot and you'll figure it out."

~~~
throwawaymath
True, but that likeness is normally taught in abstract algebra without
requiring category theory. For example this:
[https://i.redd.it/yqnbigi032i11.png](https://i.redd.it/yqnbigi032i11.png)
doesn’t require any category to understand.

~~~
nerdponx
Not my point.

For education, there is a happy medium between providing theoretical context
and hand-waving over technicalities and learning by example.

Very nice diagram though.

~~~
throwawaymath
To give credit where it's due, that diagram is from a /r/math thread:
[https://www.reddit.com/r/math/comments/99y547/my_digram_of_a...](https://www.reddit.com/r/math/comments/99y547/my_digram_of_abstract_algebra_and_other_stuff/)

------
nerdponx
My rule of thumb for explaining things to people is "start specific and
generalize."

This goes the other direction. Which is sometimes useful, but can be hard to
follow unless every step is meticulously explained _and_ its necessity is
justified.

~~~
gnulinux
I think this is very personal and you shouldn't assume this for everyone. I
personally find general -> specific MUCH better, in fact this is how I learn
mathematics. I first learn group in abstract, then I study dihedral group,
symmetry groups etc... If done the other way around I'm always confused as to
what are rules of the game.

~~~
SkyMarshal
Same. I generally prefer to see the forest first, then understand how all the
different trees fit into it. Similarly when looking at a map, I very quickly
want to zoom out and see where in the bigger scheme of things is the small
thing I’m looking at situated.

Same with more complex concepts in math or CS - it helps me understand and
retain them better if I know where they fit into a bigger scheme. Category
theory is particularly interesting in this regard, as it serves to connect
different branches of math into a mesh of Categories and Functors describing
their interrelationships.

------
k__
Most people learn inductive, not deductive.

They know how to map an object into an array or an array into another array.
Many even know how to flatMap promises that resolve to promises.

But they don't know that they follow general rules that make their behavior
predictable.

~~~
btschaegg
On another note, I suspect that the main problem everyone faces when
explaining monads to someone who is not familiar with the term is "caused" by
the dominance of C++-like programming languages.

Monads and functors are not really all that complicated per se, but because
C++ templates and Java-style generics are not able to operate at their level
of abstraction, people that are only used to thinking in these terms fail to
map them into their "comfort zone" and usually give up. And instead of
pointing out that monads are on a higher abstraction level, you get statements
like "monads are like burritos"[1] which only confuse people further.

The explanation that finally made sense to me was when someone didn't only
explain things in the abstract and them link them to the next ridiculous non-
programming thing, but instead laid out the basic operations and then pointed
out that options, lists and asynchronous tasks are monads _because they
support those operations_. I was basically in the exact situation you
describe.

Of course, that people can't agree on a single terminology to save their lives
doesn't help either (return vs. lift, bind vs. flatMap vs. SelectMany). From
the outside it's like one of those math papers where you spend a day figuring
out which non-standard notation they used in order to understand the equations
in it.

[1]:
[https://blog.plover.com/prog/burritos.html](https://blog.plover.com/prog/burritos.html)

~~~
zozbot123
> because C++ templates and Java-style generics are not able to operate at
> their level of abstraction, people that are only used to thinking in these
> terms fail to map them into their "comfort zone" and usually give up.

That's what "patterns" are for, in C++/Java and any low-level languages that
don't provide the level of abstraction you're after. Functors and monads are
patterns in these languages, just like subroutines are a pattern in assembly
language but not in C, and "objects" or "closures" are patterns in C but not
in C++/Java. Monoids are usually called the "Composite pattern", hence saying
that monads are monoid objects is just stating that they share analogies with
the Composite pattern at a higher level of abstraction. So what's the problem?

~~~
btschaegg
> That's what "patterns" are for, in C++/Java and any low-level languages that
> don't provide the level of abstraction you're after.

Keen observation. If you read through most explications for monads that float
around the internet, though, you will find that design patterns are usually
introduced to the reader with much more didactic care. Texts explaining, say,
the Command Pattern will usually try to lead the "average" (or even junior)
Developer to understanding by providing motivation ("let's write an Undo
feature!"), introducing new concepts in the context of some simple, but
usually tangible scenario ("let's say we have this editor…") and explain
things in terms of the stuff the reader can be assumed to know already.

Even if you look for explanations of monads aimed at non-FP developers,
usually they start with something like "For some monad `M`, …", followed by
either mathematical expressions or some very abstract function signatures in
Haskell (which a majority of readers has probably never seen before). At that
point, you already have lost 90% of the audience.

I have yet to try to explain the concept to an unsuspecting colleague, but if
I were to try, my approach would be to start with familiar things. For a C#
dev, this could be LINQ, for example. In this case, you could even get people
pretty far, since the inline query syntax is pretty much just a do notation
that was bludgeoned with an SQL hammer. If you then point out how other things
than IEnumerables and IQueryables (IObservables or Tasks, for example) work in
similar ways and could be treated the same way, I suspect you should be able
to nudge the average C# dev along far enough to give them a basic
understanding of the concept and some of the upsides without instantly
resorting to single letter type signatures.

I'll really have to try that sometime.

------
rmrfrmrf
(The problem, in fact, is that the significance of monads in Haskell in terms
of the side-effect model has nothing to do with category theory. The "side-
effects" quite literally occur outside of these theoretical constructs.)

~~~
danidiaz
The laws are important though. They ensure that the "statement-like" things we
build out of expressions do behave like statements.

For example, it would be weird if we had three statements A B C that wrote to
console, and sequencing A with B and then sequencing the result with C
resulted in a different program than sequencing B with C and then sequencing A
with the result.

Or, for non-IO things: it would be weird if we had three levels of nested
lists, and concatenating two times "from the outside" resulted in a different
list than concatenating each inner list first, and then the outer list.

------
rgoulter
Further reading (at a much slower pace):
[https://bartoszmilewski.com/2014/10/28/category-theory-
for-p...](https://bartoszmilewski.com/2014/10/28/category-theory-for-
programmers-the-preface/) Has examples in C++ and Haskell.

~~~
yannis
His videos on you tube are also very informative.

------
casion
Its offputting to me trying to learn these things when Im lost at the very
first sentence of the explanation.

------
miguelrochefort
I thought I was smart before reading this.

~~~
RGamma
I'm sure this would be something you could learn for yourself as well.
Category theory/logic/universal algebra/etc don't require any magic; they do
require you banging your head against them for some time though...

~~~
miguelrochefort
I got it now. It's burritos all the way down.

------
voidhorse
Thus is a great exposition on some of the relationships between the entities
of the theory and Haskell, which a lot of papers that exploit CT don’t always
make clear. Bravo on that score.

I wish some of the category theory driven Haskell tutorials would swap out
their “prove the laws” exercises with implementation exercises. While it’s
great to be able to prove the laws yourself, part of benefit of using an
existing theory as an underlying model is that you get to take advantage of
the laws (and long history of proofs and developments it took to ascertain
said laws) to create implementations or gain particular insights—it seems like
it’d be a more useful exercise for programmers to implement some programms
utilizing the ideas rather than proving te laws yet again—this seems like a
more expedient way to develop insights as to how you would actually use these
structures.

------
ginnungagap
A similar "joke" in mathematics is that "a sheaf of groups is just a group of
sheaves" (meaning that a sheaf of groups on a topological space X is a group
object in the category of sheaves of sets on X)

~~~
tprice7
Here's a fun puzzle: concretely, what is a group of groups?

~~~
ginnungagap
An Abelian group

------
wwarner
I suspect that constructing your models with these logical rules and running
them and their interactions through a proof checking compiler like Haskell's
could help with concurrency, security, large code bases, refactoring and more.
And yet what we get are solutions to problems that we don't really have.

------
learneracct
What are the steps to learning category theory? Preferably something with
solutions so I can check my work?

~~~
mathgenius
I would highly recommend the book by Lawvere and Schanuel: "Conceptual
Mathematics: A First Introduction to Categories". It is a very down-to-earth
introduction to category theory, written by two masters of the field.

~~~
smadge
I second this recommendation! I agree with the sentiment expressed by some in
these comments that intermediate category theory probably isn’t going to help
you too much as a programmer. However the introduction to Category Theory in
“Conceptual Mathematics” caused me to understand sum types, product types,
algebraic data types, finite state automata, logic, and functions as objects
in a new way. Additionally “Conceptual Mathematics” isn’t arcane or
inaccessible they mention in the introduction (or maybe it was a review of the
book) that a motivated high school student could use the book for self study.

------
platz
Basically what's going on:

with monoids, you can combine things, and then monads result from choosing a
clever combining operation in a certain contexts

~~~
krapp
That makes them sound like union types to me, but I'm guessing they're not
like union types, otherwise that's what they would be called.

~~~
mlevental
Union/sum types don't combine things though? you can only have ever one
variant at a time. it's a misnomer. monads and monoids combine things in the
sense of joining them. e.g. lists are a monoid because you can concatenate
(they're also a monad for the same reason).

------
nraynaud
funny, I was recently looking at a very smart algebra (Guibas and Stolfi) that
was making really easy to express transformations I absolutely did not care
about, but not that easy for what I wanted.

~~~
drcode
I notice that's the same Stolfi that runs the r/buttcoin subreddit, as a
cryptocurrency guy I've had arguments with him before LOL.

------
agumonkey
It is.

