I imagine most programmers who develop an interest in category theory do so after hearing about monads. They ask someone what a monad is, and they’re told that if they really want to know, they need to learn category theory.
Unfortunately, there are couple unnecessary difficulties anyone wanting to understand monads etc. is likely to face immediately. One is some deep set theory.
“A category is a collection of objects …”
“You mean like a set?”
“Ah, well, no. You see, Bertrand Russell showed that …”
There are reasons for such logical niceties, but they don’t matter to someone who wants to understand programming patterns.
Another complication is morphisms.
“As I was saying, a category is a collection of objects and morphisms between objects …”
“You mean like functions?”
“Well, they might be functions, but more generally …”
Yes, Virginia, morphisms are functions. It’s true that they might not always be functions, but they will be functions in every example you care about, at least for now.
Category theory is a framework for describing patterns in function composition, and so that’s why things like monads find their ultimate home in category theory. But doing category theory rigorously requires some setup that people eager to get into applications don’t have to be concerned with.
Patrick Honner posted on Twitter recently that his 8-year-old child asked him what area is. My first thought on seeing that was that a completely inappropriate answer would be that this is a deep question that wasn’t satisfactorily settled until the 20th century using measure theory. My joking response to Patrick was
Well, first we have to define σ-algebras. They’re kinda like topologies, but closed under countable union and intersection instead of arbitrarily union and finite intersection. Anyway, a measure is a …
It would be ridiculous to answer a child this way, and it is nearly as ridiculous to burden a programmer with unnecessary logical nuance when they’re trying to find out why something is called a functor, or a monoid, or a monad, etc.
I saw an applied category theory presentation that began with “A category is a graph …” That sweeps a lot under the rug, but it’s not a bad conceptual approximation.
So my advice to programmers learning category theory is to focus on the arrows in the diagrams. Think of them as functions; they probably are in your application [1]. Think of category theory as a framework for describing patterns. The rigorous foundations can be postponed, perhaps indefinitely, just as an 8-year-old child doesn’t need to know measure theory to begin understanding area.
More category theory posts
[1] The term “contravariant functor” has unfortunately become deprecated. In more modern presentations, all functors are covariant, but some are covariant in an opposite category. That does make the presentation more slick, but at the cost of turning arrows around that used to represent functions and now don’t really. In my opinion, category theory would be more approachable if we got rid of all “opposite categories” and said that functors come in two flavors, covariant and contravariant, at least in introductory presentations.
There are two kinds of computing: scientific and business. They have little in common: less today than when FORTRAN and COBOL were invented; little enough even then; less tomorrow than today.
Each speaks of its own as if the other did not exist. This is…potentially confusing. Granting the impossibility of saying anything non-trivial about both at once, it would still be simple and wise to specify which is being discussed.
Every time I’ve approached category theory I’ve gotten bogged down in the theoretical underpinnings, so this sort of approach seems perfect to me as a working programmer. Are there any sources you’re recommend that take this sort of practical approach?
“Area” tells you how much paint you need to buy.
A “monad” (in Haskell) lets you decide what a semi-colon does.
My big gripe with the Category Theory for Programmers genre is that so often the punchline is something like “look at all these programming things that can be seen as instances of CT concepts. NEAT!” If CT is to ever make deeper inroads into software engineering there needs to be a whole lot more. “Here’s a messy programming without CT concepts. Here’s how thinking in terms of CT makes the program better!”
@Ben: I agree. There are some moments when category theory helps, but are there enough to make studying category theory worthwhile? The answer’s not clear, and it varies by person.
As I’ve written about before, category theory is most helpful, in my opinion, when it’s in the background. It might suggest an idea that you present in other terms. For example, categorical ideas informed the design of Microsoft LINQ, but they certainly didn’t expose that to users.
@Egg Syntax: You might try The Book of Monads.