[motohagiography]

The way that CT is explained to engineers here is what tech architects do every day, and with the rigour of formalisms that would help clarify a lot of the muddled thinking some architects suffer from. Arguably, an architect is someone who uses categories and relationships between them to solve and optimize for aggregate behaviour and outcomes.

I watched the first guest lecture, which was very good. I'm not a mathematician, engineer, or a category theorist, but I can apply the formalisms to system architecture instantly.

[skybrian]

I guess, but I'm reminded of the promises made for UML, where in the end it just introduced some standard conventions for whiteboard diagrams.

Abstract, domain-independent formalisms can make ideas harder to understand than domain-specific, concrete examples. With category theory, I'm not seeing examples of the formalism paying off that would justify the endeavor.

[zozbot234]

UML did not have a categorical foundation in the way that, e.g. commutative diagrams, tensor networks or proof nets do, though. Categorical foundations help define some implied properties and allowed operations (e.g. "diagram chasing" as a diagrammatic representation of composition) that have no equivalent in ad-hoc modeling notations like UML.

[skybrian]

Sure, it's real math, but is that a difference that makes a difference? The real-world applications could still be overly hyped.