As someone with a maths degree, yet who admittedly hasn't looked into category theory beyond some basic notions, I still don't quite understand why anyone would want to learn category theory before e.g. abstract algebra or even just fundamental mathematical reasoning (definition, theorem, proof).

Maybe I'm missing something but it seems to me that all you can study monads in programming languages without having to also learn the category theory abstraction of it. The same goes for semigroups, monoids, folds, functors, ...

I'm sure there's a benefit in category theory once you want to unify all these abstractions and talk about all of them together, but I see so many people who think they have to learn CT before they can understand monads in e.g. Haskell, and I don't really understand why.

I would be willing to drink the kool-aid if I saw it being used in a practical way. I always feel these posts are filled with category theory jargon without ever explaining why any of the jargon is relevant or useful. I’ve even watched some applied category theory courses online and have yet to feel I’ve gained anything substantive from them.

However, as I started off with, I’m always willing to try something out or see the reason in something. Can anyone give me a practical applied way in which category theory is a benefit to your design rather than just creating higher level jargon to label your current design with?

I strongly recommend this presentation: "John Baez: "Symmetric Monoidal Categories A Rosetta Stone"[0]. It is easy to get lost in the ocean of theorems and definitions and overlook some powerful core concepts.

[0]https://www.youtube.com/watch?v=DAGJw7YBy8E

> Category theory is really the mathematics of abstraction

Mathematics is the mathematics of abstraction. That's all you're doing in math, from the beginning to the end. What's the same between "I have two sheep in this pen and five in that one" and "I have two apples in this basket and five in that one"? Hmm, you can abstract out 2+5=7, since it works the same in both contexts.

Everything in math is creating and exploring abstractions. The good ones tend to stick around, the bad ones tend to be forgotten.

Category theory is the mathematics of composition. How much knowledge can you throw away and create reusable patterns of composition? How many interesting things can you find by adding back the smallest bits of additional structure on top of that minimum? How well do those things compose together, anyway?

As a former category theorist: don't learn category theory unless you're already rich or want to do it for fun.

It will be a lot less rewarding than you expect RE: your engineering ability/understanding.

Bartosz Milewski's series of lectures on YouTube is a really engaging and enjoyable introduction to category theory. These are really helping me get it. https://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI...

As a programmer and hobbyist math reader, I found category theory to be very unrewarding (and I gave up on it) because of the lack of interesting theorems and lemmas. My takeaway was that there's Yoneda lemma and really nothing interesting before you reach that. Like, CT describes a set of rules but very little emerges from those rules.

My complaint has nothing to do with whether CT is useful or practical. By contrast, abstract algebra can be taught (e.g., in Herstein's books) as pure abstraction (very dry and without presenting any real-world connections), but you reach Lagrange's theorem right away -- which is an simple-but-awesome result that will wake up your brain. You reach Cayley's theorem and others quickly, and each is more exciting that the last. And this is all while still in the realm of purely-abstract math.

I became very interested in CT from a biological perspective. The work originates from Robert Rosen who describes how biological/complex systems are not (completely) reducible to formal systems (aka any model of a natural system will always be incomplete+it is impossible to explicitly list out all the rules governing the system) because they "contain a model of themselves" to which they anticipate the future and act on towards their benifit.

Many relate his work as closely tied to Gödel's incompleteness theorem but for biology. The purpose of using category theory is that it is general enough to not talk about specific parts of an organism's construction, but rather how their general functional parts relate to each other.

This crowd may not want to hear this, but as a former mathematician, the DS/Algorithms knowledge I gleaned from Leetcode grinding has been far more useful in my day-to-day work than any of the category theory I once used on a regular basis.

I find CT highly fascinating, worked through parts of 7 Sketches in Composability and have a functional programming background. I see the appeal, but I came to the conclusion that my time is better spent observing, learning about and designing with abstractions like monads, applicatives and so on rather than to learn the theory behind it.

There seems to be a tiny handful of people that can use category theory as a resource to craft something relevant to software (the stereotypical example in my mind being Edward Kmett of Haskell Fame), but I am certainly not one of them, and that is not something that would change with learning more Category Theory (whatever that might mean: Proving some theorems, discovering more categories, ...)

To the author: I am looking forward to a retrospective at a later time. I wish you a good journey, happy diagram-chasing!

> Category theory is literally the mathematics of boxes (objects), arrows (morphisms), and composition.

As I've learned more about category theory (and its applications), I've found string diagrams to be a really nice tool. But string diagrams flip the above around -- morphisms are boxes, and objects are wires. A wire is just a point-to-point link; it doesn't do anything on its own, it just connects a port of one type with a matching port on another site. It's the graphical realization of the composition operation itself.

Meanwhile, morphisms are the things that actually have behavior and real identities, so we draw them as boxes with inputs and outputs and give them names. This lines up with my understanding that in category theory, it's the morphisms that matter; the objects are no more than labels governing how you can stick the morphisms together. You may as well call the morphisms "widgets" or "components", and call the objects "interfaces", because that's literally correct.

This ends up really nice in the context of distributed systems, where concurrency gives you a monoidal category. In string diagrams, concurrently is quite literally the result of putting two diagrams side-by-side, rather than connecting them end-to-end. It's lovely, and some of the research I'm doing right now is actually founded on formalizing the message-passing causal diagrams distsys researchers and practitioners use every day, and using them as a vehicle for building programs that are more amenable to being proven correct. (Distributed systems are hard to verify for both humans and computers; I'd like to think that what I'm doing will be just as good for giving human practitioners a good framework for convincing themselves their code is correct -- or better, making bugs more obvious.)

Honestly, this is a waste of time and is not going to help as much as the author thinks it is. There is no secret from category theory that will make one's design 10x better. Not everything is even applicable.

>I hope that category theory will allow me to formalize my intuitive understanding of abstraction, put words to it, and use those words (or, better, words others have written) to explain my thinking.

Note how this goal doesn't include anything about improving the author's software engineering ability. The goal is to be able to use category theory to describe existing concepts. Why not us just describe it in ways that 99% of software engineers already understand? Why not learn good software design directly instead of through a subset of category theory which you have to translate?

Category theory is very helpful when looking a programming from a metadata / multi-domain interactions perspective aka (interaction between different abstraction layers / non-linear scip )

Although, applying CT to lisp ( . ) bit more handy (to quot(.) or quote()

Cool, I am also spending a little time on this. I bought a CT book by Emily Riehl but I am finding it rough going.

I find her YouTube talks and lectures to be easier to follow.

As opposed to “why am I learning category theory”, which is usually screamed deep in the night before an exam.

Super cool-- love the discussion around diagrams and why they're so critical to humans

I worked through a popular Introductory Category theory text. Did all the problems and made sure I understood everything in there really. It became clear by the end why some mathematicians like category theory. It lifts some results in certain areas to a higher level of generality.

As for me it helped me with understanding some of what was being discussed on r/haskell. It didn't help one iota getting me a Haskell job though, failed every Haskell code pairing I've done.

I recommend "how to bake pi" by Eugenia Cheng for a high level introduction, followed by her in-depth (but still approachable) book "The Joy of Abstraction"

I am also in the process of learning cat theory, I don't have a cs background, but I ending working as full-stack developer because it was economically more rewarding, I will recommend to programmers to have a good understanding of set theory, binary relations and order theory (linear orders, partial orders, lattices), it gives you very powerful abstractions that allow you to write new algorithms about anything.

You learn category theory for intellectual curiosity. I learn category theory to pass a Haskell course. We are not the same.

Reading at the comments, people confuse concepts like monoids and functors with category theory.

Category theory? Learning something when you don’t absolutely have to in order to write code? Sure it might be fun and expand your mind but I’ll have none of it you understand! Bah humbug!

Related discussion. https://news.ycombinator.com/item?id=33740089

I tried this a couple of years ago. However it went over my head I think I need more fundamentals before I can approach this again.

My professor told me that learning category theory would make me a better person but not a better programmer

To obviously debunk any and all FP autism coming at your way.

To give credit where credit is due, most of the time some application functionality being described through FP jargon gives a better spec of its behavior than the same through OOP jargon.

Will it make you a better React dev tho?

I’ve become increasingly obsessed with set theory. I think we can derive set theory from Turing machines and basically “solve” incompleteness.