Software patterns as a symptom of failure?

If you have to use them, maybe your programming language is just not powerful enough?

By Rick Jelliffe
February 14, 2010 | Comments: 5

The most interesting comment I have read recently about the pattern language movement is the comment that Gang of Four style software patterns are only necessary when the programming system (programming-in-the-large and programming-in-the-small) does not have adequate power or capabilities to directly state the pattern.

(I have lost the reference to who made the comment: any ideas? I think it was made in relation to Scala or LISP.)

So if your language has abstract iterators and supports XML, perhaps there is less need for a separate concept of visitors? Or if you language has object with private members or methods, perhaps there is less need for the concept of a facade. If you language supports generics, is there much so need for the bridge pattern?

I haven't made up my mind, but it is an appealing idea. The message I take home is that perhaps the GoF-style software patterns should be used as a kind of top-down analysis that we can use to judge programming systems: a programming system which has a first-class story for each of the community-acclaimed software patterns is better than one which does not.

Does this open the door for a fairly objective way to test between different programming languages? Rather than saying "That language X has a feature Y that is really neat!" we can say "Language X has a feature Y that is really neat and it supports pattern P". Which is not to say that support for patterns is not the only criterion: but when a language does not have a good story for supporting a particular software pattern, it is extra work and risk if it turns out that that software pattern would be appropriate.

The thought strikes me that this may be a way to explain the popularity of the dynamic languages (and perhaps of jQuery too?) (which the new generation of static languages like Scala are influences by too): do they support the well-known GOF-style software patterns more easily? Do they support patterns like Abstract Pattern simpler?

Now, please, I have not come to bury Software Patterns, but to praise them. The ultimate target for Software Patterns may not be the programmers they were initially design fore, but for programming language designers.


You might also be interested in:

5 Comments

Are you looking for Design patterns of 1972 ?

Aristotle: Great! That was not the thing I read, but I bet it was the thing that inspired it! Thanks for the link.

Key quotes: "Patterns" that are used recurringly in one language may be invisible or trivial in a different language.

...that many patterns aren't really addressing recurring design problems in object-oriented programs; they are actually addressing deficiencies in object-oriented programming languages, and that in better languages, these problems simply don't come up, or are solved so trivially and so easily that the solution doesn't require a "pattern".

The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.

Glad to help. :-)

Be sure to follow the follow-up links at the bottom of the article, and its follow-up links in turn. There’s even more line of argument where that article came from – lots of food for thought.

Rick, maybe this is your reference:

http://paulgraham.com/icad.html

Citation (from the end of a long article):

For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. ...

Helmut: Yes the Graham article is the one.

And it references Peter Norvig's 1998 Design patterns in dynamic languages.

News Topics

Recommended for You

Got a Question?