“Yet, the most popular form of software patterns is exemplified by those found in Design Patterns, by Gamma, Helm, Johnson, and Vlissides, which contains little more than techniques for coding in C++ constructs found in other programming languages– for example, 16 of the 23 patterns represent constructs found in the Common Lisp language…. Down with quality, up with clever hacks. Why worry about what makes a user interface beautiful and usable when you can wonder how to do mapcar in C++.”
— Richard P. Gabriel in “Back to the Future: Is Worse (Still) Better?”, 2000
“This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about ‘patterns’. I wonder if these patterns are not sometimes evidence of case, the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough– often that I’m generating by hand the expansions of some macro that I need to write.”
— Paul Graham in “Revenge of the Nerds”, May 2002
Peter Norvig (of Google fame) appears to have done the initial work on identifying the 16 Lisp constructs that correspond to the Gang of four patterns. Here’s his talk where (i think) he first made that point back in March of 1998. He reiterated these points at a presentation in October 1999 and he said that Lisp is the best host for first class patterns.
What blows my mind about all of this is that these discussions are all taking place in the nineties. The nineties! And in spite of that knowledge, we end up today in pretty much the same place even in 2007:
“More than half of the code in every Java enterprise framework exists purely to work around well-known, deliberately chosen limitations at the language level. Smart Java developers have paid a staggering price to prop up the illusion that the Java language is easy.”
For the past eight years I’ve struggled to make my programs as dynamic and configurable as possible. Many times I’ve thought to myself, “what I really need to do is write my own language for solving this type of problem.” I’ve literally thought that a half dozen times before reading a word of Paul Graham’s essays…. The idea seems so natural, I always wondered why it felt like I was the only person in my niche that wanted to do that. And it seems that the answer to that is that the development environment I was locked into was specifically engineered to make it difficult to do those things–it even made it difficult to even imagine doing those things.
This is pretty disappointing….