A monoid is a category, a category is a monad, a monad is a monoid

Not a criticism, just a note to anyone thinking of spending an hour with it.

[1]: http://www.lambdadays.org/lambdadays2016/philip-wadler

[2]: http://www.lambdadays.org/static/upload/media/14562260715188...

[3]: https://youtu.be/aeRVdYN6fE8

http://stackoverflow.com/questions/3870088/a-monad-is-just-a...

But I didn't really try to understand it.

It was once a teeming garden world, but after replacing every species several times, the increasingly abstract creatures failed to thrive. Many wars were faught, poisoning the planet itself with leaky abstractions and broken factories.

They knew many years ago, the planet was dying. The most enterprisey scientists of the world gathered in secret to build a colony ship, free from abstraction. A chance to start over and build a more functional place.

And now on this new planet, they cast off the old ways of objects and threads, embracing monads and async promises for a better future. This time, the scientists reasoned, it would be better. And so they replaced their first species, the monoid.

For my own part, I find this kind of post fairly easy to digest, but that's almost certainly because I'm a Mathematician by training (PhD in numerical differential geometry, but did a lot of abstract algebra as an undergraduate). To me, a lot of the programming-related topics on HN seem to be written in some form of Ancient Greek, but they seem to be pretty popular and attract a lot of comments.

I think we have to simply assume that there are minorities of niche experts on HN, and that these minorities are large enough for such posts to do well.

It's actually a lot more accessible than it seems at first—these ideas are not complex, just abstract. Thinking at a high level of abstraction is very much a skill which requires specific training, but it's a skill worth training and, when you have it, learning things like this becomes much easier.

The same thing is true of programming, by the way: once you start "thinking like a programmer", it becomes much easier to learn a new programming language or to understand some low-level programming concepts. And thinking like a programmer is, in the grand scale of things, not that different from thinking like a mathematician!

This stuff is a certain brand of abstract algebra. Abstract algebra is generally of a certain degree of usefulness to a programmer in that there's a similarity in discipline. Moreover, linear algebra can be very useful to many programers who do things related to applied mathematics---nearly all of it touches linear algebra. Linear algebra is a specific form of abstract algebra and this blog takes a particularly "abstract" approach to linear algebra.

The particular tools being used here are of a category theoretic flavor. Category theory is a sibling to abstract algebra especially popular in certain fields (topology, algebraic geometry, foundations and logic). It's furthermore pretty popular in the Haskell-like FP crowd since Haskell is a rich place for exploring very high-order abstraction and category theory helps provide some language for talking at very high abstraction. For that reason, a lot of Haskell hackers have some amount of experience with category theory.

Finally, hackers with any kind of pure math background have a decent chance at having been exposed to this stuff. Even if they weren't, there's a good chance they could read it with some fluency. Math is a lot like programming where once you get your water legs you have a significantly improved time digesting related subjects even without direct prior experience.

For myself I have a bit of a math background, was drawn to Haskell for that reason, discovered category theory via Haskell, then swung full circle and read about it as a branch of pure math to learn more about foundations and logic.

So you go to the Wikipedia and learn there is a word "class" (no more complex than a word "bunch" at all, in my opinion) and there exists simple, very much set-theoretical explanation of what is (or might be in different set-theory systems) a class, and why it might be not a set sometimes.

Then he starts with arrows, and again, from the explanation it isn't immediately obvious why he can't use a word "function" instead (and it is immediately obvious when you read definition of category on Wikipedia — and I got used to the fact Wikipedia isn't the best source by far when trying to learn math).

So, my real complaint is these guys are consciously not using mathematics (because math texts are "scary" — and, yeah, I agree, they often are) when essentially explaining mathematics. Category theory isn't some different discipline, it isn't "superset" of mathematics — it is mathematics. Informal is good when it isn't "imprecise", otherwise it's just useless and harmful. I sometimes think it might be easier to actually get used to (once more all over again) all math-talk and read something like "Categories for a working mathematician", instead of trying to decipher all these "simpler" informal explanations.

To say "only God can understand the future" is an unnecessary personification of our incompleteness. I think the future of declarative functions is pretty clear. Today foo(x) = 2x, tomorrow foo(x) = 2x. Anything we can't say is simply a dearth of information. How useful is it to say we've a dearth of "future information"?

Anyway, we give names to sets of propositions, and that's a neat trick.

If god was all knowing, he could create a cryptosystem he himself could not break.

God is a bad measure of physical properties. Some things are just unknown.

An example which may speak to a programmer more: the set of functions which take a 32-bit int as argument and return a 32-bit int, where the operation is composition of functions. The identity is the identity function. Since not all functions are invertible, this monoid is not a group.

I would love you to go into more detail, though probably only for all the wrong reasons (such as my own entertainment).