For those interested in a little more rigor, there's a great series of lectures on the subject that was just posted online from Steve Awodey, who wrote one of the best introductory texts on the subject.
The article argues against overly formal approaches, but I actually think it errs too much in that direction. When I'm studying a math thing, at some point I need you to shut up with the English words and simply describe the object in terms of sets, functions, relations and properties. Categories stopped being mysterious for me once I realized they were just multigraphs with a certain algebraic operation defined on edges (composition) such that edges with certain properties (identities) were stipulated to exist.
Ha, I actually read his last sentence as sarcasm initially and thought "haven't I heard this joke..." only to find that you had already referenced the one I was thinking of:
"A monad is just a monoid in the category of endofunctors, what's the problem?"
I didn't mean to imply it was trivial to understand, but it's no more difficult than the formal definition of, say, a derivative (which involves a limit, and hence an epsilon-delta construction, which in my experience are not so easy to fit in your head at first). Understanding what a multigraph is should be doable.
I suspect that that explanation only works on people with a fairly specific background. I think the hope of the article is to target a wider range of people who could benefit from understanding the formalism.
> More specifically, the common explanatory route to approach categories is usually: “here is a formal specification of what a category is; then look at these known things from maths and theoretical computer science, and admire how they can be described using the notions of category theory.” In practice, quite a few people only adopt conceptual objects by abstracting from two or more contexts where the concepts are applicable, instead.
(Note the instead.)
I understand the author's point, and perhaps these examples are easier to follow for non-math people.
However, to be fair, this approach is the approach taken by pretty much every single description of Category Theory I've read. One of the first things MacLane does is provide a bunch of relevant and familiar examples (groups, rings, etc).
Just depends on your audience! Groups and rings aren't familiar at all to lots of programmers. It's fine if category theory is actually only accessible to those to whom that kind of math is familiar, but the author of this article doesn't seem to think that's the case. His bottom-up approach tailored to a very specific programming audience seems fairly unique and I think it works pretty well!
The examples the author chose are kind of hand-wavy, unix pipes in full are obviously not categories. But I recognize how hard is to come up with examples that aren't contrived and that programmers can relate to without knowing much mathematics.
That's the inherent difficulty in discussing category theory solely in terms of programming, it's hard to see the forest for the trees if you don't have a bunch of well-defined categories you can draw examples from and interrelate.
In an undergraduate course one would typically start with examples from algebraic topology which has a lot of great cross-categorical relations, like how the homology group of a topological space is an example of a functor from the category of groups to the category of topological spaces.
> That's the inherent difficulty in discussing category theory solely in terms of programming
Worse, I don't see any point in categorical models if you want to think solely in terms of programming.
> one would typically start with examples from algebraic topology
My initial exposure was along these lines as well, although the idea of a "course" in category theory seems a bit odd (not in the sense of wrong or bad, just not common-place).
Talking about categories in the context of everyday functional programming (even where the connections are correct) always seemed abstruse and a bit silly. If you're not using categorical models, what's the point (other than giving fancy names to things)? And if you don't have some background in algebra or topology and a specific research goal, why build the models?
Well I mean, there is a lot of utility in programming with categorical concepts in Haskell. There's plenty of libraries in the Haskell ecosystem that wouldn't even exist if it weren't for drawing upon category theory for guidance. Pipes is probably the best example of this school of thought on library design. [1]
My point was mostly that I don't think there is a path to really understanding the full generality of category theory through functional programming alone, one has to go learn the pure mathematics as well.
When we were having the Categories subject in Algebra II (maths degree) half-jokingly with a few friends we built a category (with operations, universal properties and objects and all that funny and weird stuff) based on the columns of the university courtyard (this one: http://blocmat.files.wordpress.com/2011/03/matefestub-ba.jpg)
+1 for actually providing meaningful contexts! This is right in line with Situated Learning Theory, to think about how your audience is full of Engineers that want relevant examples rather than abstract math.
This post is useless. The most important notions of category theory, namely universal mapping properties, natural transformations and adjoints aren't even mentioned.
It's useful for intuitively conveying the notion of what a category actually is. I think many people don't even get past this point. So that in and of itself seems useful to me.
https://www.youtube.com/watch?v=BF6kHD1DAeU