<i>"This school of thought then claims that the patterns at their scale and above are not indeed patterns, because they have no use of patterns.<p>This thinking is flawed in two ways. The glaring flaw is in the restrictive definition of patterns. The more subtle flaw is in not recognizing that they have patterns of their own at similar scales to the ones that were rejected. Abstraction is extremely powerful, but operating at higher levels of abstraction doesn't appear to imply higher productivity or reduced needs for patterns as a medium for sharing context."</i><p>The reason we don't get a boost in productivity with higher abstraction is because (a) we have to build such abstractions out of a great number of smaller pieces, so that 'greater abstraction' means 'more work', and (b) it is just very difficult to map our mental models into reusable abstractions. Not very many people can do it well.<p>Yes, every language has 'patterns', but we call those linguistic structure, syntax, or grammar. "Design patterns" refers to something else, (or if it doesn't, it is just a confusing domain-specific renaming of the above.) The problem with design patterns is that they are ostensibly <i>solved problems</i>, and thus people shouldn't be implementing them except pedagogically.<p>Take arrays for instance. There is no "Array Design Pattern", and we don't ask people to implement arrays every time they want to employ them. We ask them to use existing array structure. Yes, you should understand how they work. You probably should implement them once or twice and know how to recognize them. But you do not say "Oh, just use the array pattern here. Start by rolling your own array, since our language doesn't have array syntax."<p>We build arrays into the language so that they are easy to recognize and the pattern becomes a primitive tool. If you have to keep rolling your own, you'll never get past that. It will never become primitive, and you will stagnate. That is what those who object to design patterns object to: by thinking of them as elements of design -- the work of day-to-day programmers -- we won't provide linguistic abstractions that allow them to become primitive tools. We'll be stuck re-rolling our own arrays because people think that this is what programming is all about. Tedium.
Programmers by and large don't seem to understand the power of language primarily as a communication tool and the lessons around communication we ought to understand. We think in solitary terms as if it is of primary importance how we write code individually instead of how we communicate with each other (and the machine).<p>Patterns if done well give us a language to solve problems in sensible ways as teams.<p>Instead, we worry about how patterns are named and argue over minutiae. We let things like "exceptions should only be used for exceptional behavior" distract us from effectively communicating with each other.<p>Our industry sees things like FP, OOP, Design Patterns, etc. as an exercise in taxonomy when building software is an exercise in communication. It's like we are writing a novel, but we are more worried about the names and families of characters than the actual plot itself. That doesn't make for a good book and it doesn't make for good software.
In my experience, design patterns encourage two big problems:<p>- Deciding on a solution before having explored the problem. "I have a pattern for that."<p>- They act as shared context only on the surface; all the details and subtleties of the pattern as an implemented artifact are rarely shared, and communication suffers.<p>In practice, they tend to make the easy stuff easier, but the hard stuff harder.
To me patterns have always been incredibly useful as a book of problems that have been solved, somewhat like a chess playbook. Would I ever implement them directly? Maybe, if they were directly appropriate. Often I find that my solutions are pattern inspired, "factory-like," "observer-like," "strategy-like" etc. Even more frequently my solutions are a hybrid of multiple patterns.<p>That's where I see their value: they are extremely good blueprints. Like every tool, they are incredibly powerful if used correctly. They are most often misused, especially in the case of verbatim use.
The author suggests a common opinion on patterns, that I have seen violated a billion times:<p>> Two people with a common set of patterns find it easier to communicate [...] than those without one.<p>> [...] writing down our shared context lowers the barrier to entry.<p>In my experience this is often not the case. Patterns come along with labels and the labels will be put everywhere in a codebase. Assumptions get made and replace discussions, leading to a diluted codebase. For example Repositories will become synonyms for "thing that does database access", and will then be reduced to stupid GetByID wrappers [1]. Even worse, some patterns make entry really hard.<p>I used to work with C# and ASP.NET MVC. There, a view is the thing that contains markup, the thing controlling the input is the controller. Then I started using Flask and was utterly confused, since there the functions with the @app.route decorators, which are run on the server and then return markup rendered via jinja2 templates, are called view functions. In Django this is understanding is the same.<p>I was really baffeled. I could not reapply my understanding of the patterns across these domains. This is just one explicit example that I wrote about in my blog [2], but I really made the general experience that patterns replace or inhibit discussions, rather than improving communication and understanding.<p>[1] <a href="http://philcalcado.com/2010/12/23/how-to-write-a-repository/" rel="nofollow">http://philcalcado.com/2010/12/23/how-to-write-a-repository/</a><p>[2] <a href="http://www.cessor.de/on-patterns" rel="nofollow">http://www.cessor.de/on-patterns</a>
Would patterns exist if we had no name for them? In my opionion, definitely yes. So giving them a name doesn't change the nature of patterns. Problems arise when a, now named, pattern gets misused. The misuse is therefore <i>always</i> commited by the developer. The two main critic points I've read in the comments were:<p>- Developers try to find a problem to use a pattern they know<p>This error is mostly commited by people who learn the first time of patterns and are giddy to use them. I wonder if this was less likely to happen, had the GOF included a warning about this in their book.<p>- Developers keep using the wrong terminology and this causes patterns to become squishy<p>Just stick to the GOF terminology and your good to go.<p>In my eyes, the patterns discussion is just an indicator for a greater "problem": Anyone can become a software developer. I won't elaborate on the positive aspects of this. But it's clear that areas with a higher entrance bar, like law or health, have a greater professionalism and, among other advantages, a standardized terminology.
> The critics may be right that it devalues the craft, but we would all do well to remember that the craft of software is a means, not an end.<p>I don’t think that patterns devalue the craft.<p>Also they helped me get a better understanding of what I do. For example in Python you can create a Singleton by simply accessing an instance which is instantiated directly in its module. The pattern is built-in and very easy to use, but I only started making heavy use of it when I learnt the Singleton pattern. It was then that I realized how much value this simple language feature provides.<p>> “In a functional language…you end up programming in concepts that eliminate design patterns all together.”<p>I saw lots of ad-hoc patterns which have to be understood to understand the code.
I was a bit confused whether the author argues for patterns as Platonic idea, patterns as popularized by GoF or patterns as popularized by Christopher Alexander.<p>The most vicious arguments I have read were about GoF not keeping the spirit of CA. One example is GoF being a sort of disconnected catalogue, while CAs patterns are supposed to generate the world. I don't see these referenced in this article.
I disagree. Patterns are often just used as a way to work around the limitations of expression in a given langauge. Sure, they can be useful. But in the long run, they are not the goal, they are the unfortunate means to an end.