And then you wake up to the fact that most programmers are really bad at higher abstractions and especially mathematics. They start off way better than general population too...
But they can deal with nested smaller abstractions or impure smaller abstractions just fine.
It is easier to think of a set of logic properties than essentially equation describing construction of an object with such properties. And that is the difference between the design pattern and a category.
To put something in a mathematical category you have to actually prove it constructively or you're doing adhockery.
And due to so many levels of abstraction nesting proving anything nontrivial in maths is really a chore at times.
A simple example: prove some operation is a Strategy morphism compared to describing it as an object with a set of properties.
> most programmers are really bad at […] mathematics.
I wouldn't be so sure. Many of us got into programming to flee what we often call "mathematics". But the stuff we learned in school is quite different from actual mathematics (rote application of recipes, and tedious exercises, mostly).
I'm pretty sure we can teach maths to those traumatised programmers. Just don't utter the "M" word so they don't recoil in horror.
Monoids for instance are a deeply mathematical, yet very simple concept. And useful too: want to do map-reduce? make sure your binary operation is associative (meaning, make sure your stuff is a monoid), or you won't be able to parallelise your reduce step.
And you made the mistake here just as I expected. Map-reduce does not require associativity as long as you know the order of the operation execution. (Or error due to operation reordering is bounded and acceptable.)
You break the assumption any time you use floating point math.
Then you've added a property to an operation that does not require it.
Many "math types" like to do such things to simplify proofs and there you end up with variations of spherical cow results, either in applicability or performance.
> Map-reduce does not require associativity as long as you know the order of the operation execution.
Good luck knowing that order when using a magic map-reduce to parallelise things for you.
> You break the assumption any time you use floating point math.
You're just nitpicking here.
Either I care about the non-associativity, and I have to control the ordering of the reduce operation (the best one might be a parallel bottom-up merge), or I don't care, and I'll be using -ffast-math already.
It is not nitpicking. Either a property is true or it not. This is exactly the point article author is making when resisting design pattern ambiguity.
If you cheat you will get invalid results sooner than later. Essentially bugs. Sometimes trivial, sometimes a billion dollar rocket explodes.
If you use math name but lie about it is even worse than if you don't use the concept at all.
For example a String despite what author says is not a Monoid in almost all languages as catenation (operation +) is not strictly associative. (Because memory allocation is different!) Yet he does this mistake...
Hey, you brought up floating points. I talked about monoids, not floating points. I don't even make the assumption you say I break when I use floating points. Of course floating points aren't a monoid, let alone a group or a field.
> catenation (operation +) is not strictly associative. (Because memory allocation is different!)
What the hell are you talking about? The ordering of operation influences the address of the result? Who ever cares about that? Even in C, you don't rely on the value of such addresses —only their uniqueness.
I don't know if they're bad at higher abstractions, or if the pay-off of a higher abstraction isn't always there (or is unclear).
The original comment did a good job of illustrating this. It's not clear from this post what category theory can do for a person programming with design patterns in mind (in other words, how will it change their behaviors?).
Unless you somehow teach people to actually run math proofs on the fly, it won't do any good either way if they start using mathematical descriptions since they will still "fake out" the math.
It is like trying to teach calculus by showing baked approaches at solving integral equations.
Just because you call a thing a Monoid does not mean it is one. Similar in how people use the design patterns in real life, except these do not demand clarity and of you partly misnamed it people are not confused.
But they can deal with nested smaller abstractions or impure smaller abstractions just fine.
It is easier to think of a set of logic properties than essentially equation describing construction of an object with such properties. And that is the difference between the design pattern and a category. To put something in a mathematical category you have to actually prove it constructively or you're doing adhockery.
And due to so many levels of abstraction nesting proving anything nontrivial in maths is really a chore at times.
A simple example: prove some operation is a Strategy morphism compared to describing it as an object with a set of properties.