This is a phony work in progress (I do not mean to disparage the author, just the work itself, or perhaps the YC submission). There's no direction, it's just "let's do it because ... ?" Here is the authors' answer to "Why Category theory?":
>The answer lies in the abstraction and generalization capabilities provided by category theory. It allows us to see beyond the specifics of a particular programming language, problem, or system, revealing the underlying structures that are common across different domains
Rest assured you will not find much of that by reading category theory (CT). This type of studying of CT reminds me of Shaolin monks trying to fight boxers (hint: the boxer wins).
Another peculiar thing about these notes is that the author colored every CT diagram (and worse even, there is no logic to the color choices, it's just randomized.)
CT is a nice subject as any other, and useful to those doing research. You don't need it if you're not doing specific math/CS research that uses it. Anything that could be useful to you from CT can be explained in one afternoon over some coffee or beer. For example, the notion of universality could be useful to many programmers: the "most general" object of its kind, and how that is reflected in relation to other objects of its kind; a brief example would be that the "free" language of all strings in the letters A and B is universal amongst all languages of strings A, B with relations, (relations such as AAAB = A.)
Don't enter turbulent waters if you're not a swimmer! Maybe you can take a boat instead. For those who already know CT because of other motivations (in particular, because they're mathematicians who have spent many years studying mathematics), the applications of CT to computer science can come somewhat naturally, but for others, it's an uphill battle and a waste of time.
IMO Bartosz Milewski gave a pretty good answer to the "why" question in the preface to his book:
> Second, there are many different kinds of math, and they appeal to different audiences. You might be allergic to calculus or algebra, but it doesn’t mean you won’t enjoy category theory. I would go as far as to argue that category theory is the kind of math that is particularly well suited for the minds of programmers. That’s because category theory — rather than dealing with particulars — deals with structure. It deals with the kind of structure that makes programs composable.
Composition is at the very root of category theory — it’s part of the definition of the category itself. And I will argue strongly that composition is the essence of programming. We’ve been composing things forever, long before some great engineer came up with the idea of a subroutine. Some time ago the principles of structured programming revolutionized programming because they made blocks of code composable. Then came object oriented programming, which is all about composing objects. Functional programming is not only about composing functions and algebraic data structures — it makes concurrency composable — something that’s virtually impossible with other programming paradigms.
During an afternoon someone who understands the concepts can explain the relevant parts without requiring an understanding of CT from the other party. Hence: don't bother with CT.
I don't mean to be rude, but what has Bartosz Milewski done that is relevant in programming?
> I would go as far as to argue that category theory is the kind of math that is particularly well suited for the minds of programmers. That’s because category theory — rather than dealing with particulars — deals with structure. It deals with the kind of structure that makes programs composable.
I would argue this shows that Bartosz Milewski has no idea what programmers actually do. Programming is all about the particulars. Programmers are the ones who have to think about and ask "but what if the person's last name in their country of birth includes characters which our OCR system can't reliably discriminate" or "but what if an attacker sends us a small UDP packet with a spoofed source IP, will we send a lot of data to that IP and spam them?".
Programming is very, very rarely about abstract structure. We programmers are the ones who have to handle of the myriad nitty gritty details of abstract ideals, not the other way around. Sure, sometimes a nice abstract library can solve certain simple recurring problems. But that is a minute minority of all programming work. And if you don't enjoy getting your hands dirty and finding out how many pixels actually fit on the screen, or what exactly happens to bit 15 of the output register when bits 5 and 7 of the control register are set and the input signal is larger than 1024, then you won't last long in the profession.
I'm not, not at all. I'm just pointing out that programmers are people who learn to, and like to, delve into the details. Architecture is fun, but it's a tiny part of the job, ultimately.
The biggest part of a programming job is pinning down the details of your requirements.
Pinning down the details of your requirements is _exactly_ the act of choosing the correct level of abstraction. When picking out what matters for correct behavior, and what doesn't, you are defining an abstraction.
Sure, but abstraction is not in any way the same thing as architecture (which is what you were talking about), and it's not structure (which Bartosz Milewski was talking about).
And besides, Category Theory is mostly concerned with finding similarities between different mathematical objects, when you look at them abstractly and ignore some details. It helps you find that numbers with adding are homomorphic to functions with composition. But programming is about telling a computer how to actually add 156 with 1571 by adding bit to bit, and how to compute the composition of two functions by computing the result of the first and putting it in a register so the second one can take it as input, which CT doesn't concern itself and no category theorist cares about in the slightest.
> programming is about telling a computer how to actually add 156 with 1571 by adding bit to bit
programming can also be about producing generic solutions that commit to some minimal set of assumptions so that solutions work across a variety of contexts, e.g. regardless of whether your data is floats or ints.
sometimes good engineering is about finding decisions you can avoid making or thinking about. Sometimes you have to decide how to add the numbers bit by bit, but for that particular example, it's even better to not care about how the numbers are added up (which is a detail of the CPU or a bignum library or whatever).
>The answer lies in the abstraction and generalization capabilities provided by category theory. It allows us to see beyond the specifics of a particular programming language, problem, or system, revealing the underlying structures that are common across different domains
Rest assured you will not find much of that by reading category theory (CT). This type of studying of CT reminds me of Shaolin monks trying to fight boxers (hint: the boxer wins).
Another peculiar thing about these notes is that the author colored every CT diagram (and worse even, there is no logic to the color choices, it's just randomized.)
CT is a nice subject as any other, and useful to those doing research. You don't need it if you're not doing specific math/CS research that uses it. Anything that could be useful to you from CT can be explained in one afternoon over some coffee or beer. For example, the notion of universality could be useful to many programmers: the "most general" object of its kind, and how that is reflected in relation to other objects of its kind; a brief example would be that the "free" language of all strings in the letters A and B is universal amongst all languages of strings A, B with relations, (relations such as AAAB = A.)
Don't enter turbulent waters if you're not a swimmer! Maybe you can take a boat instead. For those who already know CT because of other motivations (in particular, because they're mathematicians who have spent many years studying mathematics), the applications of CT to computer science can come somewhat naturally, but for others, it's an uphill battle and a waste of time.