@mnl@hachyderm.io

The value of Category Theory for a pragmatic programmer

I'm really starting to be able to formulate the value I get out of category theory for my down-to-earth programming, and it feels great having it all come together.

One thing that I think is not well taught regarding category theory for programmers is that most of the work stays in the category of types with functions as morphisms and only illustrates the “canonical” version of the structures studied. It's always tuples for products, interpreters for algebras and catamorphisms, etc...

I think it would be much more interesting to showcase that morphisms and objects can be anything.

Since everything can pretty quickly be made into a category or be handwaved into something close enough to be helpful as a category in the context of programming, you can apply the structures studied in category theory to anything (even beyond just types and functional programming).

Communicating about abstraction is really hard in the best of times, and using terms from category theory doesn't help much in day-to-day life, as they will probably confuse people who don't know them (and we all know that it's not something you pick up with a quick google).

Seeing the product when parsing a date

But being able to see, say, a product structure when parsing a date into a year, month, and day, and what that implies in terms of refactoring, is extremely useful. It's something that most developers get to intuitively, just through programming, but what they might not see is how widely it can generalize and how useful it is as a generative pattern.

Parsing a string into a date tuple means I can keep the string, or I can keep a tuple of integers, or I can embed the date in a bigger struct, or I can actually concatenate the string with something else. All the functions on (int, int, int) will still work because I can compose it with the parsing function to have them work on strings.

Sounds trivial, really, but I think there is a lot of value in putting a single, simple word on it.

It's easy to forget that seeing that a string for a date is the same as a parsed version of that string as a tuple is a simple refactoring pattern.

Many junior developers don't know that don't see that, and now I have a simple diagram to show why that is the case, and I can generate 27 more concrete examples of the pattern using that diagram.

I don't need to mention the word category, morphism, or product to do so; I can use it mentally to generate examples. That way, the more junior person will be able to develop the intuition through repeated exposure to concrete examples. At that point, I can jump in and formulate the theory (again, not in category theory terms, but in programming terms).