“Just when I thought I was out, they pull me back in.” — Michael Corleone, The Godfather, Part 3
My interest in category theory goes in cycles. Something will spark my interest in it, and I’ll dig a little further. Then I reach my abstraction tolerance and put it back on the shelf. Then sometime later something else comes up and the cycle repeats. Each time I get a little further.
A conversation with a client this morning brought me back to the top of the cycle: category theory may be helpful in solving a concrete problem they’re working on.
I’m skeptical of applied category theory that starts with categories. I’m more bullish on applications that start from the problem domain, a discussion something like this.
“Here’s a pattern that we’re trying to codify and exploit.”
“Category theory has a name for that, and it suggests you might also have this other pattern or constraint.”
“Hmm. That sounds plausible. Let me check.”
I think of category theory as a pattern description language, a way to turn vague analogies into precise statements. Starting from category theory and looking for applications is less likely to succeed.
When I left academia the first time, I got a job as a programmer. My first assignment was to make some change to an old Fortran program, and I started asking a lot of questions about context. My manager cut me off saying “You’ll never get here from there.” I had to work bottom-up, starting from the immediate problem. That lesson has stuck with me ever since.
Sometimes you do need to start from the top and work your way down, going from abstract to concrete, but less often that I imagined early in my career.
One thought on “Getting pulled back in”
I am interested in your way of applying category theory to computer science and/or software design (patterns). If possible, please provide some reference that can provide a better insight (and example) of this application. Thank you very much.