Design Patterns Are Missing Language Features

This is the assertive, positive answer to the question: AreDesignPatternsMissingLanguageFeatures?

Opposite View: LanguageIdiomClutter, Weaker View: MissingFeatureSmell (design patterns indicate missing language features)

If DesignPatternsAreMissingLanguageFeatures then DesignPatterns are explicitly not patterns in the sense of ChristopherAlexander. The patterns of ChristopherAlexander as outlined in TheTimelessWayOfBuilding are not fixed building blocks (as implied by being extractable into libraries). Instead those patterns can be realized in many different ways depending on the present forces to resolve these forces.

Note: This does not mean that this is a bad thing, only that it is a strong difference to the ideas of ChristopherAlexander about patterns. See also SoftwareDesignPatternCritique.

Patterns are abstract by nature... in general, any observable pattern (be it spatial (nouns) or temporal (verbs)) is something like a madlib proposition with little 'blanks' where you can fill in a few details. I don't imagine the situation here is as meaningfully different as you're implying. ChristopherAlexander's patterns were, of course, largely limited to the spatial... but they were still patterns. Patterns, being abstract by nature, can be extracted into libraries by means of providing 'blanks' or parameters by which to instantiate them, thus allowing these patterns to be realized in many different ways depending on the motivating forces. Of course, language libraries that aren't ConstraintProgramming driven will tend to 'fix' the implementation of the other fraction of the pattern even in the case where higher-level patterns allow for multiple concrete implementations (just as the fixed words in a madlib can name high-level abstract patterns themselves, like 'dog' or 'ceiling'). This fixed implementation is a matter of practicality that doesn't at all contradict the notion of patterns.

So I've my doubts that this is as 'strong' a difference as you state - not when talking on a fundamental level.

Regardless, as you indicate, while Alexander's use of the words 'DesignPatterns' and 'PatternLanguage' may have inspired and influenced adoption in our field, it can't be considered a bad thing that in adapting it for the software domains we focused upon patterns in a software environment where we, unlike Alexander, have the ability to fully automate instantiation of patterns by use of parameterized statements. Nor is it a bad thing that we recognize our unique ability to fully encapsulate (within limitations determined by the programming language - those lacking procedures or templates or macros can be quite limited) many such software patterns into libraries of procedures and objects such that they can be shared without rebuilding. While a little less artistic, this ability is critical to keeping software systems cheap.

Frankly, I expect we've gotten more out of our adaptation of DesignPatterns and PatternLanguage and taken both of these further than our source of inspiration ever will. It is time for the master to learn from the student.

I agree that it is essentially possible to mold any pattern into a software artifact/lirary/language feature - after all that is what software is about: Modelling anything that can be thought. Software is like language and thus allow arbitrary phantasy whereas buildings are constraint by physics.

I hate it when people talk like that. Software is also constrained by physics... just more of the signal, temporal, and information-theoretic variety. And both software and architecture suffer resource limitations. Any language of sufficient complexity will allow you to make statements that are false or impossible, but software doesn't allow actualization of such arbitrary fantasy.

But I'm not so sure if we in our arrogance shouldn't learn something from Alexander. The theoretical possibilities of software of modelling patterns are still a long way off. We do not yet have AI. And we also do not have the possibility of making most pattern - in particular not the kind of patterns of Alexander - into artifacts. Observer, Visitor, Proxy and State are very simple minded patterns that can, but others like Modul, Mediator, Layering, Adapter or Bridge are more difficult in general. These really must be adapted themselves to the forces resolved by them.

I said we have learned from Alexander... his influence inspired the patterns movements in software.

In any case, the programming language is what determines the limits of what can and cannot be captured into a pattern. You point to observer, visitor, proxy, and state because they are examples having solutions in languages with which you're familiar, but there's not a chance you could capture those patterns in a language like SnuspLanguage, and even supporting them in C would be difficult. So don't make generalizations about what is possible or impossible without carefully considering the possibility of adjusting the language to support patterns or support their refactoring into libraries. I already know of general mechanisms, for example, to approach the AdapterPattern - approaches that simply aren't provided without deep code integration and hand-implementation on a per-case basis in any popular programming language, and BridgePattern is already captured indirectly by your choice of abstract base classes and programming modules with abstract interface support in several programming languages: FirstClassTypes or FirstClassModules would be the only addition required to readily make BridgePattern itself into an artifact. A pattern is sufficiently captured as an 'artifact' - a language feature or library component - if the programmer doesn't need to implement its structure and process by hand and doesn't need to modify all the could impacted by it for each distinct application.

I propose a weaker statement: patterns that can't be either directly implemented or readily turned into a re-usable library in a language indicate that the language is missing a feature. If such a library must leak implementation details to the client modules, this is a strong indication of missing feature(s). See MissingFeatureSmell

Take as an example the ability to create and iterate over a list of things that are of varying types (but have enough similarity that iterating makes sense). CeeLanguage would make this a very difficult proposition, but LispLanguage, RubyLanguage, and others make this very simple. We can't say that there is a single missing feature in C, but that there are multiple features that could be added to C to create a new hypothetical language that would make this a reasonable proposition. Object oriented extensions would work. Run-time type information or dynamic types would also be helpful.

It would be interesting to see a pattern shootout using various languages and/or paradigms, similar to DoubleDispatchExample and EveryCombinationInManyProgrammingLanguages.