I also heartily recommend this. I’ve been watching the videos whilst ploughing through the PDF book version [1] on my Kindle. He really is a very good teacher.
Just another opinion on this: I don't think "Category Theory for Programmers" is that great from a pedagogical perspective. I get that its freely accessible, but like the "Haskell from First Principles" book, the quality of the exposition is a bit questionable.
Call me old-fashioned, but when it comes to learning math, I believe it pays to seek out people who really know how to teach the subject, rather than (what might uncharitably be described as) self-promoters churning out half-baked introductory materials. This goes for the "Catsters" video series as well. Everybody points to them as if they're brilliant, but compared to what standard? Sometimes it feels as if the people who blithely link to these resources are indifferent to whether the teaching is good or bad.
Even Mac Lane's book "Categories for the Working Mathematician" has been credibly criticised for being poorly written—but because it's so famous/prestigious it still gets loads of five-star reviews.
Personally, I'd recommend Categories and Computer Science by RFC Walters, or Steve Awodey's Category Theory for a more general overview.
(This might all sound peevish, but it feels like a real hazard of trying to learn difficult things from the web: the most conspicuous and superficially charismatic offerings/lecture notes/blogs don't always turn out to be reliable or well thought-out when it comes to an average person actually trying to learn the material.
Monads are a good example of this bad situation. A good way to learn about monads would be to have a few, shortish, interactive conversations with an expert. Ten thousand cute online monad analogy tutorials is the opposite of this: it's actively counterproductive because each new analogy just creates more vagueness and FUD.)
I get the feeling there are two very different paths towards an understanding of category theory. Moreover, I feel these paths either don't quite converge or only converge very slowly.
The roads are:
* Through experience as a type-system in e.g. Haskell
* Through experience using this in pure mathematics
From my experience, it seems that trying to swap between the two paths at the start is reaaally confusing. You need to stick to one path until it makes sense. Then perhaps later, you can get back to the other path. The point where "it makes sense" is when you get out of the toy-examples and manage to put it to actual use. My hypothesis is that: because the first actual usage examples are so different between the two paths, switching only confuses you.
Obviously, this doesn't mean sticking to a single source. When you get stuck on one source an alternative explanation is great. It just needs to stay within the same path.
I definitely think you're on to something. I think there are two types of math people among programmers:
* Math heads that make their way into the CS world, and for loops were harder to understand in the beginning, but Set algebra makes sense.
* Programmers by trade that have had to deal with the math side of things that probably learned for loops at age 10, and seeing sigma and epsilon symbols drives them totally nuts.
I'm in the second group and I definitely say I live off content created by people that came into it the same way.
Shorter answer: there are Java people and there are Python people.
I also found Awodey's category theory more helpful than Milewski's ramblings (though I appreciate his effort). Maybe it's because I find "applications in theory" worth learning.
If I may try to point out what's missing: it is the motivation which seems to get lost for lack of examples.
Here's a theory, called category theory, and many of us believe it can inform their designs, providing a perspective on compositionality, and a higher kind of equational/algebraic reasoning.
Where are the ideas and examples that will actually help us inform or designs and achieve a higher degree of compositionality? Where is our chance to apply algebraic reasoning to the programs we write?
So I will provide a lot of C++ examples. Granted, you’ll
have to overcome some ugly syntax, the patterns might not
stand out from the background of verbosity, and you might
be forced to do some copy and paste in lieu of higher
abstraction, but that’s just the lot of a C++ programmer.
Maybe this would work, but we don't actually see it in Bartosz's posts. As a different example, take Wadler's papers on comprehensions and monads (rendered as Kleisli categories): the motivation is very clear, we'd like to express certain programs/queries within a functional programming language, and all examples contribute to an understanding.
What should an experience programmer learn? One suitable answer seems to be the connection of lambda calculus with products and CCCs. That, though, would also need motivation for "functional programming", referential transparency. An alternative answer could be to point out the connection between topos theory and logic (or query languages).
It almost seems that when flipping to Haskell examples, Bartosz is making a leap that let's him ignore the motivation: anybody who is writing code in Haskell won't need to be convinced of referential transparency. There is simply a forest of "patterns" and category theory seems to be a systematic path through it. Maybe potential applications in physics provide a similar motivation for physicists.
... but if you don't bring the motivation yourself, you're not going to get it from reading the posts.
Thank you for the detailed comment. It was exactly what I was looking for. And I agree with you. I find it frustrating and inefficient if I'm just presented with the theory without any applications.
I also believe that to really understand and get an intuition for a concept, you need to see it applied, preferably in different contexts.
I agree... Also, thing is, Category Theory is so abstract that no amount of tutoring may be enough for a person to feel really at home with it. As with other abstract branches of mathematics, the only way to really understand the value and the meaning of what the theory is all about is through months and months of hard personal mental effort and training.
I’ve been slowly reading through Steve Awodey's Category Theory, but as someone with not much math background it’s a bit dense. He does have some nice lectures online which help, but I’m not sure how far my understanding would have stretched without reading Bartosz first.
To be fair, I’ve come to CT through Haskell development, which Bartosz caters heavily towards. While it is absolutely not necessary for the daily aspect of my job, it really helps drive home the underlying mechanics of the language.
That all said, now it’s brought me in a roundabout manner to wanting to learn more advanced math, although while I am grasping CT I can’t understand what people are talking about when they compare it to pure mathematical concepts (Sets, Groups, Rings, etc), which tends to be frustrating. I am attempting to find a path to understanding all of this without having to grab another 4 year degree.
The way this book is so wonderfully illustrated and written is why we need more women in math/tech. I haven't read any paper/book on abstract math/category theory that wasn't extremely dry and boring
Hmm, on what factual basis did you come to the conclusion that there is a strong association between author's gender and illustrative nature of a math/science writing?
My team at work has been studying CT. Every week we read one chapter of Category Theory for Programmers. Then every Thursday we discuss the chapter and our problem solutions together.
It's been very fun. Our discussions help forge links between the category world and our day-to-day programming. We're only 3 chapters in, so I can't say it's given me some huge insight into programming. But as we move from Go to Rust/Typescript, it gives us a useful way to think about the correctness of our programs and a useful shared vocabulary for talking about types in a language-agnostic way.
My workplace is the exact opposite. They scoff at types let alone categories. One guy literally told me, and I kid you not, that he doesn't need type checking, all he needs is to be "careful."
We don't learn things together, instead what happens is if I present something new, another person stays silent looks it up at home on google and comes to work the next day pretending he's an expert on the topic. It's toxic.
Truth to be told, learning Category Theory will make you a better software engineer in the same sense and to the same degree as learning Quantum Field Theory would make one a better electical engineer. It might get you more excited about your profession, but at the practical level it will be more of a distraction than an aid.
YMMV massively depending on what exactly you're working in.
I've found when I'm writing libraries that will be leveraged by other programmers, especially in a modern/high level language, insights I've derived from my understanding of category theory have been incredibly valuable.
If you're working very close to the metal (eg, embedded), very close to non-technical users (UI stuff, edge layer business logic), or in less featureful languages, then you'll get much less value.
As someone interested in functional programming, but works almost entirely in imperative languages, is category theory worth learning?
Function programming heavily impacted how I write imperative code. Would I have similar revelations with category theory – maybe write better abstractions?
> Would I have similar revelations with category theory – maybe write better abstractions?
Maybe, but it's not a given. (Haskell folks might have a different view due to their language being a closer match to the theory)
My sense is Category Theory is one of those things that is useful for explaining things in retrospect, rather than used as a constructive tool. It exposes inconsistencies in your current model, and helps clear up your thinking. John D. Cook wrote a piece on Applied Category Theory which makes the point that theory itself is perhaps less useful than the discipline of thinking categorically [1].
I think Category Theory can guide the design of certain types of tools that deal with relationships. LINQ (in C#) for instance was guided by category theory. If you wanted to come up with a new kind of SQL, category theory could be helpful in designing abstractions that are orthogonal and clean.
But the design of these types of tools remain a small, specialized domain within programming. It's somewhat analogous in my mind to metaclasses in Python: classes are sufficient for the most part, only framework developers will likely ever need metaclasses (to generate classes).
In most day-to-day programming, it seems unlikely that category theory will have as much an impact on practice as does, say, simple principles derived from functional programming. In fact, there may even be negative consequences from over-abstracting your code.
Some light category theory is pretty useful (functors, monads, lenses, etc). However, I think it often goes way overboard into premature abstraction territory with many functional programmers. The type tetris required to make some of this stuff compile, and the mental overhead, can easily exceed the abstraction gained.
The category theory should also be viewed as more a close analogy to the programming problem, rather than an exact correspondence. These abstractions sometimes leak, especially in numerical code.
edit: More complex and specialized abstractions are useful on fewer problems than simple, general abstractions. In addition, they have more mental overhead. So you work harder for a less useful abstraction, and you make it harder for others to use and understand your work.
Yes. Very much so. Especially if you're programming functionally. It will explain why all this is the way it is. Why sum types and product types are what they are, the big picture on functors, monads, etc, etc.
I like Bartosz Milewski's introduction [1][2] where he states (paraphrasing) that he started programming back in the day with assembly, and as programs got more difficult we needed higher level abstractions, so he moved to procedural languages, and then after that another higher abstraction was OO, but he realised that OO has a fundamental problem: objects don't compose, and so he found himself functional programming with Haskell... each time looking for better abstractions.
Category Theory is the ultimate abstraction and although you can't write code with it, you can step outside of the detail of complex solutions and think about the bigger picture and then use that bigger picture to help you build your detail. And that's why I think it's valuable.
I particularly like his journey too, as it exactly reflects my own.
You ask as if it is somehow a huge investment. Category theory is not that hard. It became the language of (almost all) contemporary mathematics. Many mathematicians learn it during the first years of their studies. Its core is very small, and most (if not all) of its usefulness comes from the language itself. In other words, there are almost no theorems in (pure) category theory, but there are many definitions and a great deal of examples. If you know at least some abstract algebra, learning category theory will be quite easy. And this language opens the door to conceptual understanding of many areas of mathematics, logic, functional programming, and some other applied sciences.
It can be useful, precisely as much as any formal framework can help guide your thinking. Categories suggest a particular type of abstraction. It's highly abstract. It can be quite useful. However, if you find another algebraic formalism, that can be useful also.
I found this really useful. I've had multiple, unsuccessful attempts at grokking category theory, and never really felt I got it. The closest was John Baez's online course [0].
I don't have a particular aptitude for maths (as an engineer by training, maths makes sense to me as a tool for solving problems - not as a source of study in and of itself).
Most all the introductions to CT I've read get into the maths very early. That's entirely understandable. I personally find I need a more intuitive description of the concepts first, using non-mathematical exemplars. OP is, thus far, the introduction that best articulates things for me in those intuitive terms.
That's in no way a criticism of more formal/abstract treatments: I've great admiration for those who naturally create and assimilate things that way. I wish I was one.
This is the first explanation of Category Theory that I could relate to. I'd tried reading into it before, but quickly lost ground with all the theoremizing going on. As is typical with mathematics, once you understand it, it seems trivial. But getting there is not. So thanks for the map.
Set theory is a foundation for modeling abstract structures. Category theory is a foundation for modeling abstract structures together with structure preserving relationships between them.
(Once one has identity relationships then in fact the structures themselves can be disregarded and one is left with a study of simply structure preserving relationships.)
He also covers it all in few youtube series - https://www.youtube.com/user/DrBartosz/playlists