How does understanding category theory help a software engineer?

Question

This question is related but doesn't directly answer my question.

I can imagine that understanding category theory helps someone who is designing a programming language, apparently in particular functional programming languages.

But what I find hard to understand is, how would a software engineer benefit from a knowledge of category theory, who has no interest in designing a new language, but just wants to solve practical problems.

Could you explain any benefit it has? Let's assume the software engineer who writes in functional programming languages. How would he/she benefit from a knowledge of category theory?

I would like to get a more illustrative answer than merely "it helps you to understand functional programming better", because I've heard multiple lectures on category theory make a claim like that, but it has not become clear to me how, practically, it actually helps you.

Answer 1

The basics of category theory might help you to understand the essentials of composability. If you've come up with similar solutions to different problems you might want to understand the key factors which make those solutions possible. Even if learning this field might not have immediate practical impact for you, it could help you to ground your understanding which in turn is beneficial when exploring new languages or concepts. It could also help you to be faster when trying to build data structures and functions which have to have certain properties.

Some programming languages like Haskell even took those concepts and named them explicitly in their libraries (monoid, functor etc. are all present there).

Mark Seemann has written an extraordinary collection of articles on his blog: From design patterns to category theory

Answer 2

Most people would strictly define "understanding category theory" as "I can understand a lecture on category theory given by a mathematician who doesn't know how to code." However, a lot of aspects of category theory have leaked into functional programming in a very practical way, so a "practical programmer" definition of "understanding category theory" is usually more like, "I fully understand what monads and similar constructs are, as defined using my programming language's type system, and know how to create and use them in real programs."

This latter understanding is very useful to a practical software engineer. It describes a very common pattern of reuse. Say, I see someone use map on an instance of a type I know nothing about. I can generally assume it works like every other functor I know, and I usually don't have to look up its documentation. Likewise in reverse. If I am working with a brand new type Foo[A] and I want a Foo[B], I know from my experience with functors that I should try map first. This is true even for the "weird" types. If I understand how to use map on a list, that understanding transfers for using map on an IO.

It basically creates a shorthand for communicating about operations. This is sometimes a two-edged sword, because people who don't understand the shorthand can be left out. For example, if I want to generate random numbers in a pure manner, I might find a search result that says a certain function returns an IO Int, and that's pretty much all I need to know to use it, but we get a fair number of questions of people not knowing how to "get the Int out" of the monad.