[tsimionescu]

> 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.

[FrustratedMonky]

Yes. The 'purity' of math versus the 'messy reality' of the real world.

Sure, programmers deal with more stuff, like formatting a date/time.

The argument would be that if you follow some of the ideas in composability, then it makes dealing with the real world easier.

Like defining your structure in a way that you don't get 'leaky abstractions' when dealing with the real world.

Just because programmers have to deal with mess, doesn't mean you can't spend some time learning how to organize to minimize mess.

It sounds like you are arguing against studying architecture.

[tsimionescu]

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.

[Warwolt]

Your own words betray you.

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.

[tsimionescu]

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.

[gugagore]

> 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).