For a first introduction to category theory, from the masters thereof, I would highly recommend the book by Lawvere and Shanual "Conceptual Mathematics: A First Introduction to Categories". It almost doesn't look like a mathematics book, but believe me, these guys know what they are talking about. They distill some very high-brow ideas down to something us mere mortals can grok.

I watched a little less than the first half of Bartosz video lectures and I still don't see what the fuss is about from the perspective of an engineer that is looking to get better at engineering.

I can't find something there that would help me implement better systems. What I do see is an attempt to shoehorn a mathematical model onto certain programming paradigms in order to be able to say that these paradigms are instances of the model. In short, a lot of talk about abstractions (or "abstract nonsense") but very little of engineering significance. Please let me know if I'm missing something by listing concrete examples of how category theory can help me with engineering problems.

Disclaimer: I'm not a mathematician.

I think that the most plausible way that Category Theory is going to improve your life as an engineer is that it will sneak into the way your tools are designed.

You don't personally need to know about the Yoneda lemma to benefit from a better designed programming language whose type system was informed by algebras of types, allowing it to leverage exhaustive pattern matching.

With that said, learning about techniques used in functional programming that have their origin in category theory (maps, folds, algebraic data types, monads, monoids, etc) can allow you to think about how to solve problems (even in non-functional languages) in ways that can be more "natural" to the problem, in that the abstractions used resemble the problem description more closely. That ability to decompose difficult problems in new ways can definitely make you a better engineer.

I am a mathematician and generally bearish on category theory in programming. The best argument for it I've seen so far is that it can inform the design of your system to give it desirable properties, like how the DVCS Pijul [1] bases its data structures on patches and its merge operation on categorical pushouts [2] -- also explained at length in a series of blog posts [3]. I found the whole idea and reasoning behing the merge system very convincing, and am not sure it could have been arrived at or explained as clearly without category theory guiding the way.

[1] https://pijul.org/ [2] https://arxiv.org/abs/1311.3903 [3] https://jneem.github.io/merging/

Doesn't this post suggest you are "bullish" rather than "bearish?" Or am I misreading it?

Maybe I miswrote it. I’ve been very unimpressed with all other crowbarrings of category theory into programming than this one. Other attempts feel like language for its own sake, while Pijul really seems like a Grothendieck-style compass bearing use of category theory. The point of using it wasn’t just language, but it really informed the design of the system.

I'd say that you can safely ignore CT until you find the need or desire to learn more. The field is still very young and it probably shines most within pure mathematics, for now at least.

I think of CT as the study of "composability" in its purest form. Mathematicians are finding that this language is really good at translating domain-specific knowledge between disparate fields, not unlike the babelfish from the Hitchhiker's Guide.

FWIW, some researchers are apparently finding interesting applications in the development of biological models. John Baez has talked about applications in this direction via control theory [0].

[0]:https://classes.golem.ph.utexas.edu/category/2015/04/categor...

Let me expand a bit on the origin of category theory in mathematics.

Mathematics is most commonly described in the language of set theory, where objects are constructed from basic building blocks to create bigger blocks. This is much in the same way as algorithms are described in something concrete, say a programming language.

At some point, certain high-level constructs started to appear, where the same high-level behaviour was exhibited in otherwise completely disconnected fields. Explaining what is going on then started to become messy, for example take following quote from Hatcher's Algebraic Topology concerning covering spaces: "This is often called the Galois correspondence because of its surprising similarity to another basic correspondencein the purely algebraic subject of Galois theory". The problem is that in order to understand this, the reader has to understand two fields which are not at all connected and furthermore, the relationship looks nothing alike in the language of set theory.

Category theory was invented as a formal language which could describe such high-level behaviour. In this language this language we would could now say that there is an "contravariant equivalence of categories", which helps if you've seen it before and doesn't help at all if you haven't.

So category theory is massively useful in understanding the similarities between fields, and can be used to transfer understanding from one field to another. It it also useful for understanding more abstract fields where the intuition must be gained by analogy with something more concrete. It doesn't do much in itself, and I don't think it makes much sense to study the mathematical aspects of category theory without any good examples to apply it to.

What does that have to do with engineering? I'm not expert here, and haven't yet read the linked book, but one could hope that certain similarities could be described in terms of this new language. Then concepts which now only live on as the expert experience of working practitioners, might be written down and hence taught directly rather than indirectly. One could hope that certain problems have common solutions which can be re-used across fields.

Category theory studies the composition of (things that look like) functions. So each thing has a domain, and a codomain, and if we compose A --f--> B with B --g--> C then the intermediate B goes away. This doesn't sit nicely with how parallel composition works, e.g. If I talk to Google, that doesn't prevent you from talking to Google.

That's the essence of why category theory works nicely with pure functional programming, but beyond that simply fails to be useful. In particular, there has been virtually no progress in useful categorical models of parallel computation.

What about eg http://lambda-the-ultimate.org/node/4823 ?

I don't see much / any category theory in the two papers linked. So I'm not sure what to say.

Catagory theory is a fantastic tool for understanding programming language design. As a user, you don't need to understand catagory theory, but you benifit when the language designers do.

As a software engineer, category theory is sometimes useful in API design as well; although more often than not, your API is constrained by the existing ecosystem too much for category theory to give you much benefit (and, frankly, simple enough that category theory is overkill).

A very abstract idea of its relevance, insofar as I understand it; engineering generally boils down to putting together available things to create some whole, and category theory gives a vocabulary for describing how things (considered very abstractly) can be put together.

So for instance, one of the big applications to CS is in type systems, which describe what kinds of expressions/values can be put together, and in what ways, to create valid programs.

Most engineering is based on mathematics because proofs are a powerful support for any idea you plan to implement. It's one thing to throw something together and have it work, and a totally different thing to prove it is optimal in some way.

That's seldom how ideas from category theory are used in practice. Eg most Haskell programs aren't proven correct.

(But if you are into that kind of proving, than there are a languages a bit like Haskell, like Agda for example, that revel in those proofs.)