> But you don't _talk_ exclusively in formalisms to other mathemeticians, do you?
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.
I guess I just don't inhabit this world where there is nothing more to software design than reading and writing code. I write comments, I read readmes and documentation, and I find shared, human descriptions of larger granularity design abstractions useful. ¯\_(ツ)_/¯
> I write comments, I read readmes and documentation, and I find shared, human descriptions of larger granularity design abstractions useful.
Oh, I have nothing against that, except the word "shared". I just don't think that "design patterns" (from the GoF book) helpfully contribute to that. In practice, it really depends what you want or don't want to gloss over as a technical detail, and just saying "there is this pattern" doesn't give you enough flexibility to do it.
What I am saying there is a trade off - if you decide to name something, you should define it well enough not to be misunderstood. If you can't or don't want to define it well enough, better not name it at all (except maybe temporarily), just describe your intuitions/feelings about it. The authors of "design patterns" seem to be oblivious to this trade off (although I think it wasn't really their fault that the names for patterns got so popular, I think they just wanted to have fancy chapter titles).
It's interesting though. When I describe how something works or should work, I use terms like "client", "server", "memory", "unique random number", "sort by", "find maximum", "queue", "remote call", "common API" etc. But I never found a compelling reason to describe things in names of (standard) design patterns. Why are not these terms considered to be design patterns? In my opinion, it is because the design patterns tend to be overly specific in some ways (talking about class/interface relations) without adding enough substance to be meaningful on their own.
So I don't find them useful to describe design (overly specific), nor I find them useful to describe code (not formal enough). They are just kind of slippery for both use cases.
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.