these kind of books are "philosophical" books. In the sense that the usage can be written/explained in other ways. For instance, monads are just a way to see that if you compose two ducks you still have ducks that behave in the same manner, but that's almost the same thing as having a class and define the composition arrow as a method.

The only difference is that with CAT you have theorems asserting what's true and what's not, with classes I don't think there's much literature. A similar reasoning can be applied to neural networks as there are very different POV: someone will look at them as ODE systems, other as a pure discrete dynamical system or as an optimization problem or whatnot.

I've used it to optimize SQL. The principles I used in SQL can be used in other places as well.

I think functors are easier to understand and more fundamental to category theory and programming than monads.

Monads are fairly simple as well if you use C#'s brilliantly chosen names SELECT and SELECTMANY for the two relevant maps.

> SELECTMANY

is that a form of flatmap ?

That's exactly it, SelectMany is what in .NET corresponds to flatMap in e.g. Java. (And, unlike the parent, I don't like the narrow scope of .NET naming very much, focusing on just the list monad (a.k.a. IEnumerable).)

The idea of sharing structural properties/invariants between abstractions is something that is in my mind often, and reading the book intro resonates with me.

Domain Driven Design is essentially applied category theory:

You develop a language that models your domain, translate that into a diagram, and translate that diagram into code.

(Okay, actually topos theory since you’re going between type theories and diagrams — but you use the diagrams to move between type theories and define “equivalent structure”.)

We use it for data integration https://www.categoricaldata.net