Category theory is also very relevant to programming. But, curiously enough, learning and practicing programming is probably a better intro to eventually get to category theory, than the more usual approaches mathematicians take.
Discrete math is lots of fun, but less applicable to the kind of glue code many people write most often.
(Category theory is in some sense exactly the theory of glue code. But it's also generalised abstract nonsense.)
I don't understand how learning the definition of a limit, colimit, adjunction, pushforwards, pullbacks, equalisers, co-equalisers and the Yoneda lemma, can help you write code. But I'm willing to be enlightened.
Some starting points: tuples are categorical products (an example of limits), sum types are categorical coproducts (an example of colimits), effects are often monadic and monads arise from adjunctions, the Yoneda lemma tells you that if you have "f a" and "a -> b" and you know nothing more about the "a" then all you can do is fmap the function over the functorial value.
Sure, knowing this doesn't "help you write code" in the same way that knowing "you press the keys on the keyboard to get text to appear on the screen" but I've found this way of thinking to be beneficial to some degree when programming.
But I think that eru is trying to emphasise that one should learn how to program first and then use category theory as a tool to organise your understanding.
Do you think category theory is more useful than type theory or logic?
I’ve personally gotten a lot more out of treating tuples as product types or logical AND, and disjoint unions as sum types or logical OR, as opposed to categorical limits.
(Basically, what’s the extra value added from Curry-Howard-Lambek, as opposed to just Curry-Howard, in terms of programming?)
(I’m not trying to be argumentative, I’m genuinely curious.)
I would put category theory very far down the list of things a programmer should learn. Once a programmer has learned a lot of other things about programming, category theory can act as a good organisational and explanatory tool.
As I also tried to say earlier, in practice I suggest learning programming first, and then using the likes of category theory to organise your understanding.
First a qualification: Category Theory doesn't teach you how to write glue code, but it can be seen as a theory to organizing some of our understanding of glue code.
One simple example would just be a discussion around the different use cases of Functor, Applicative Functor, Arrows and Monads. And how they relate to common programming constructs like functions, tuples, arrays, Maybes, futures, whatever's happening in react, etc.
Category theory won't help you learn those concepts, but once you know those concepts, even a superficial understanding of some category theory, can help you organize your thoughts.
As a genuine application of category theory, whenever you find a useful abstraction (like eg functors or monads again), you can have a look at its dual, and see whether that's another interesting structure you haven't seen yet.
Just like tuples and Either are duals of each other.
(As an analogy, dualizing is also a concept in linear programming.
Linear programming can help solve many interesting algorithmic problems, like sorting or matching or assignment or median selection, basically almost anything that's in P, and if you allow integer linear programming than you can solve what's in NP.
However, I wouldn't recommend anyone who wants to learn about algorithms and data structures to start with linear programming.
But once you know a bunch of algorithms, you can re-express the problems they are solving in terms of linear programming, and see whether you get anything interesting out of looking at their duals.)
I disagree, it depends on the kind of programming you do. Build fancy typeclasses to do black magic in Haskell? Then _perhaps_. Write kernel modules for custom functionality in C? Then learning ct is like a fish learning to climb a tree.
Yes. I think programming provides a lot of interesting examples of eg functors and other such structures.
Enough to build your intuition at least, and then start learning category theory from there. (And then try to use that knowledge to kick off some further investigation into the other areas of math that category theory historically comes from, if you are so interested.)
I think it's a bit like learning Spanish first and then Latin later. Vs learning Latin first and then some romance languages.
Discrete math is lots of fun, but less applicable to the kind of glue code many people write most often.
(Category theory is in some sense exactly the theory of glue code. But it's also generalised abstract nonsense.)