[ritchiea]

Once you get past writing a language idiomatically, is a list of design patterns a good thing? It is an obvious negative for code readability because it reduces the number of people who can clearly understand your code from Rust users to Rust users who also memorize design patterns.

When are design patterns useful? And how are they useful?

[setr]

Design patterns are intended to be a description of patterns found in the wild — that is, it’s descriptive, not prescriptive.

Once distilled to their essence, and documented, and named, it becomes possible to efficiently talk about it and reference it.

They are natural things, to be found in wild codebases, that are documented and named here. That they get used and abused, or people come up with terrible names (ClassFactoryFactory) is more a lack of taste than anything — but knowing that such patterns exist and their utility is a requirement of any tradesman seeking to move above novice. The name isn’t as much needed, but it makes it trivial to google.

But again, these are patterns found in the wild — it intends to document problems & solutions that programmers have encountered, and it’s a pattern because it comes up often enough — which implies that you will likely encounter similar problems and (perhaps discovered on your own) implement similar solutions.

[setr]

Also an addendum — design patterns originate from Christopher Alexander, who was discussing the same fundamental idea but applied to natural architecture (that is, not bounded by strict regulations, laws, complex requirements, etc) in various populations; he noted that communities tend towards certain patterns and trends that work, and apply them repeatedly. But the key difference between Alexander’s pattern architecture and say, a McMansion, is the pattern only acts as a start; depending on its context (including other patterns used) the pattern is modified to fit more appropriately. And everything else is modified in reaction to that.

So the movement of a door changes how the window should be placed, which changes the best position of the sofa, which changes the ideal spot for the door, and so on. So it’s a feedback loop, approaching some optimal state where everything is in harmony with everything else (a state he calls “beautiful”, an inherent property all people recognize even if they cannot produce it themselves) — but because people live in the home, and use it and modify it and change through generations, that harmony is a moving goalpost, always sought but only possible to achieve once abandoned.

The analogy to software development is easy to make, but the key point here is that in usage, patterns are not the end but rather the beginning of a design — they can and should be modified to fit, until it is beautiful

[ritchiea]

This is a brilliant distinction, that design pattern are meant to be descriptive rather than prescriptive. Because the problems I tend to see in the wild are when developers treat design patterns as prescriptive.

[bonzini]

Design patterns are not necessarily less understandable, much the contrary in fact. They basically encode known good ways to do something, so it should be okay even for beginners who haven't learnt the patterns yet.

[ritchiea]

What's more or less understandable is a bit subjective. There are some things that are obviously less complex than others. Some things that are obviously more complex than others. And then a lot of gray area.

In my experience there is at least a faction of developers, myself among them that have a disdain for "design patterns thinking." Which I would describe as: spending a lot of focus learning various design patterns, then while coding actively looking for places where those patterns could be put to use.

In my opinion this is an anti-pattern similar to overuse of abstraction in simple cases before an abstraction adds to the understanding of the code itself, rather than makes the code more complex.

I've seen lists of common design patterns dozens of times, and occasionally recognize several of them as useful examples of things I've actually done in the past or my colleagues have done in the past. But it seems to me "learning design patterns" as an end is encouraging the destructive side of design patterns where you learn something and eagerly look for a use for it.

[paledot]

Is that really any different from leaning a language, tool, framework, library, service, etc.? You learned the new thing, you're excited to try to out, and you should still be judicious in analyzing whether this is or isn't the place for it. And some developers just want to play with the new shiny.

None of that is an argument against learning new things. Just keep adding tools to your toolbox, so you don't end up with every problem looking like a nail.

[ritchiea]

That's an interesting comparison. I can understand the argument that design patterns are just like learning another service or tool or library. But aggressive use of design patterns is taking a language we already agree on, say Rust or Javascript, and adding a dialect to the language that can easily divide the existing commonality we have within idiomatic use of the language. Design patterns just strike me as incredibly non-utilitarian, divisive and non-additive in a field that already struggles to find agreement.

I wouldn't say adding a service, framework or external library to your stack is as divisive for code readability as being a big fan of utilizing design patterns.