# Why category theory?

August 01, 2020 • category theory, programming

I don’t remember exactly when or where I first heard about category theory, but it has piqued my interest because there’s a big push towards declarative programming, in React, for example.

What is declarative programming? Quoting Wikipedia:

Declarative programming is a non-imperative style of programming in which programs describe their desired results without explicitly listing commands or steps that must be performed.

In other words, say *what* you want to happen instead of *how* you want it to happen.^{1}

So where does category theory come into the picture? Well, in programming, we break down problems we want to solve into easier subproblems (and break down *those* subproblems into sub–subproblems, if necessary) and combine their solutions together to get a solution to the original problem.

We call this act of combination *composition*. And as Bartosz Milewski says, “Composition is at the very root of category theory — it’s part of the definition of the category itself.” A declarative style of programming makes composition more obvious (think of chaining `map`

, `filter`

, and `reduce`

, for example).

Category theory gives us a formal language for talking about abstractions and composable structure. Moreover, it doesn’t care about the internal structure of things — it only cares about how they *relate* to one another. This brings to mind the phrase “Code to an interface, not an implementation.”

Given its generality, category theory has been applied to a wide range of fields, including physics, linguistics, functional programming, and database theory.

## So what?

The main question still stuck in my head is: So what? OK, great, we can do all these formal manipulations and make all these analogies with category theory, but what exactly do we gain from the effort? More specifically from a programmer point of view, how does it help us write better code?

I suspect that the major benefit of category theory is becoming more adept with abstract thinking and better able to identify related structures in seemingly unrelated things. In particular for programming, it seems likely that it will influence the design and development of your software, rather than appear as some concrete application. For example, the well-known (if not well-understood in general) concept of a monad is apparently a design pattern.

## The plan

To figure this out, I’ve decided to learn category theory. My main reference will be Bartosz Milewski’s
*Category Theory for Programmers*, along with Fong and Spivak’s *Seven Sketches in Compositionality: An Invitation to Applied Category Theory*, Fong, Milewski, and Spivak’s (draft) *Programming with Categories*, and Saunder Mac Lane’s classic *Categories for the Working Mathematician*.

I’ll attempt to explain key concepts in plain language as I learn them in future blog posts. I’ll also be writing my solutions to the programming exercises in Milewski’s book here.

- Of course, at some point we have to imperatively tell the computer what to do, but we hide that behind an abstraction layer.↩