Design Patterns – A comprehensible guide

In informal setting (like lecture or workshop), maybe not. But when publishing, you always talk in concepts that are defined formally. That doesn't mean that you use formal language all the time, but every time you introduce some definition or term, it is understood (obvious) that you could provide completely formal definition. Also, having a formal definition doesn't preclude using motivational examples.

So no, I don't think a book like "Design Patterns" could happen in professional mathematics today. Mathematicians simply don't introduce shared vocabulary of informal definitions. But it wasn't always like this - Euler used words like "curve" without having a completely formal definition (and without worrying about it). But eventually we learned this was a problem, and I think we will learn the same about programming patterns (and that's why people IMHO largely stopped trying to name new patterns).

> And I'm not saying React itself is a pattern.

Yeah, I understand, I was just taking a rhetorical shortcut. What I am saying you should be able to point at a set of functions of React and say "these embody one of the ideas behind React" (although there can be technical reasons that prevent doing exactly that on the current React codebase). Then the "pattern" you have in mind is well-defined by these functions.

> But if you think all things in the design of software are reducable to reusable pieces of code, more power to you.

I think it must be, because the "pieces of code" is the ultimate end goal. So there must be a point where the informal definition of pattern gets translated into formal code. And to do this translation reliably, you need to be able to enumerate (or parametrize) the choice of formal options that stem from the informal concept, and this process is actually the formalization of said concept.

I would say the software design patterns are rather special case, because they involve code readable by computer. In contrast, the original design patterns in architecture don't need to relate to computer code (there is no code reuse), so they are perfectly fine with not being formally defined.

Formalization, in my view, is about "knowing what you are talking about". So you have a perfectly defined set of basic operations on the concepts you use, and you know what you can do with them and what happens if you do; you cannot cheat by making stuff up as you go along.

On the other hand, abstraction deals with "how general I can make this thing" (AKA reusability).

What I mean by "formalization has won in mathematics" is that when you write a paper, all concepts you are using have to be formalized, or at least it must be obvious how they can be, typically through a shared context of standard theories (so you don't have to use formalism everywhere, although it would certainly be desirable and eventually I think it will happen).

But that doesn't mean you have to always use the maximal level of abstraction. It's perfectly valid mathematics, for instance, to prove a theorem just for Euclidean spaces even though there is nothing that could stop you from proving it for topologies. (And I think Bourbaki group learned about the cost of abstractions the hard way.)

The same is fine with code - if you think abstraction hurts it, absolutely go for lower level of abstraction. But it will hurt reusability of said code, no doubt.

But if you want to talk about some reusable concept, you should be able to show the code at the correct level of abstraction (or at least be able to show that you are able to show it).

So that's my beef with software design patterns - they are abstractions, but aren't formally defined. It's like eating a cake and wanting it, too. They are at best transient thoughts ("funny, this thing here looks awfully similar to that thing there, how so") before somebody should abstract them formally. And I cringe when people think that they help communication, because in mathematics, we already went through that.

Yes, I am aware of it. I have read Wadler's papers pointing out that list comprehensions are a specific instance of a Monad and proposing Monads as a way to structure functional programs. But I wish the Haskell did not directly copy the term Monad into the language, setting off this bad precedent. Like CAR and CDR in Lisp, unfortunately, this one will stay in Haskell. Hopefully future languages will introduce more sensible terminology, like how Lisps have evolved over the years.

> Regardless, I think it is a shame to call the same thing differently just for the sake of it.

We have to agree to diasgree on this. IMO the intended usage of a concept should dictate its name, not how humans first arrived at it.

Funny, I actually prefer CAR and CDR in Lisp to FIRST and SECOND, and I learned it only a few years ago. (It seems to me that it's more poignant since the lists are composed of cons cells.)

I think it ultimately doesn't matter - the usage of the term dictates its meaning as much as the other way around (but this can again be my mathematical background talking, which explicitly tries to unteach you to intuit based on the names of things).

Give me a single example of something that it turns out is truly better expressed through inheritance, and you will be on the shortlist for a Turing Award.