Design patterns and language design
Someone pointed me to an article by Mark Dominus on design patterns. I wasn't sure whether to be happy or unhappy. Most of what he said in the article was right on. Design patterns are not made of stone. If we had looked for patterns in 1972 then we might have said that the way we encode objects in C is a pattern. Over time, we should change our programming languages so that they build in things that used to be patterns. I think we said all this before we wrote the book. We didn't say these things in the book because we were trying to focus on the patterns rather than to talk about patterns in general. But the things he says are generally the opinion of people who write books on patterns.
The thing that makes me unhappy is that he clearly thinks that what he says is surprising. And other people think it is surprising, too. That is surprising to me. In fact, it is all conventional thinking.
At the very end, he says that patterns are signs of weakness in programming languages. This is wrong. Patterns might be a sign of weakness, but they might be a sign of simplicity. There is a trade-off between putting something in your programming language and making it be a convention, or perhaps putting it in the library. Some people like languages with a lot of features. I prefer simple languages. Smalltalk makes "constructor" be a convention. Arithmetic is in the library, not in the language. Control structures and exception handling are from the library, not in the language.
The way I usually hear this is "the design patterns are just ways of making up for the weakness of C++". None of the patterns in Design Patterns are C++ specific. Some of the patterns disappear in CLOS or Self, as we say on page 4. But these patterns are common across a wide range of languages. Many of the patterns will get subsumed by future languages, but probably not all of them. Patterns should be subsumed into languages when doing so makes programs simpler and more reliable. Moving patterns into languages will probably make the languages more complex, which reduces the reliability of programs written with the languages, but sometimes the reduction in complexity of the programs is worth it.
No matter how complicated your language will be, there will always be things that are not in the language. These things will have to be patterns. So, we can eliminate one set of patterns by moving them into the language, but then we'll just have to focus on other patterns. We don't know what patterns will be important 50 years from now, but it is a safe bet that programmers will still be using patterns of some sort.
