February 25th, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
Paul Graham’s essay Revenge of the Nerds is a nearly pornographic love letter to Lisp. If you can manage to read all the way to the end, there’s an interesting footnote buried at the bottom:
Peter Norvig found that 16 of the 23 patterns in Design Patterns were “invisible or simpler” in Lisp.
He should have opened the essay with that evidence, because it strengthens his conclusion considerably:
In the OO world you hear a good deal about “patterns”. 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.
Has anyone ever considered that design patterns are the way that programming languages evolve? In the same way as communicative language, commonly used abbreviations ( or patterns ) may become standard. In english words like “won’t” and “isn’t” are abbreviations, but are more or less considered standard words today. In the same way, ‘if-then-else’ or ‘do-while’ could be considered design patterns that have now become standard features in many languages. Perhaps later languages will include many design patterns as standard features.
Excessive reliance on design patterns is indicative of failings in the language. As many commenters in the wiki point out, you’d see dozens of “design patterns” in assembly or C code; these are language features that we take for granted today. We’ve certainly seen evolution along those lines even in the modest lifetime of .NET so far. There are plenty of “syntactical sugar” constructs such as Using which encapsulate common patterns, and even more (such as Nullable and Generics) on the way.
And in the comments:
To me design patterns are to object-oriented code as algorithms are to functional code. A good pattern tells me how to create a object or a set of objects to accomplish a given task.
Could a Langauge be extended to support patterns better? Sure. A langauge can be also be extended to make certain algorithms easier to use. Perl, python, ruby, etc make certain types of algorithm very easy to use that would require a fair amount of coding in basic, c++, or pascal.