monoid.md

There are 3 levels on this abstraction ladder:

1. "Normal" non-generic code, the kind that a regular programmer often encounters
2. General code that uses typeclasses, which unlike in typical languages don't necessarily map to any single concrete functionality in non-generic code. (Will call this the Haskell cloud) *
3. Category theory constructs, which don't necessarily map to any concrete code or whatever (just pure objects, arrows and laws that could map to anything that fits, but aren't directly connected to anything concrete). (Will call this the category theory cloud)

(*) by unlike typical languages, I mean that those at least have abstractions that isolate a concrete thing you can do to their implementation, e.g. "iterable"

By giving me the name "monoid" and mentioning category theory, you give me a coordinate that is too high in the abstraction ladder, in the category theory cloud. This is great if you can normally comfortably climb up and down the cloud in that area, and if you've already developed lots of links between (1) (2) and (3).

But if you haven't, it just puts you in a place where you can neither see the connection with (1) or even (2), nor can make sense of the connections within (3).

There is nothing wrong with the names themselves - only with the assumption that giving a coordinate in (3) is somehow enough to be helpful. I think that just widely recognizing the difference between Haskell's (2) and the pure (3) would help. That way people will know what sort of material they want to be looking at as beginners (the Haskell monoid material, not the CT monoid material).

Another thing that would help is to give precise mappings between the Haskell term and the CT term. I can't even tell what the mapping is for Monoid between Haskell and CT yet! (whats the single object?) I can only make a connection with group theory: mempty is the identity element, the method <> is the associative binary operation

Also learning the CT around Haskell currently and want to share a couple of points.

1. There is no "easy" way to understand it. Some imagination is required and also a background in several disciplines that are not thought in school.
2. There isn't tons and tons of info about it, enough so you can type any question and get the answer right away.

Because of these two factors there is no traditional path for a programmer to learn it i.e. we cannot just go language -> theory - we have to also go theory -> language and theory <-> language. Only when I understood the the theory separately from the language I could see the duality of the two which made the whole thing understandable (or even simple).

The resources that I use are two books: Category theory for scientists and Conceptual mathematics. The first one is more formal, reference-style with exercises and example applications the second is more like a textbook. Reading these goes a long way.

Also, an "object" in CT is equivalent to a "type" in Haskell (at least in this case) - so functions like a -> b that go from any type to any other form (along with the types themselves) a category, and functions that use just one type a form (along with the type a itself) a monoid.