July 17, 2002
Design Patterns Are
From Lemonodor comes a link to "Design Patterns" Aren't by M-J. Dominus a Perl person.
The book he seems to base his argument around is Design Patterns: Elements of Reusable Object-Oriented Software otherwise known as GoF (Gang of Four). This was published October 1994 as the result of work over a number of years. Perl was first released in 1987 as version 1.0. Version 5.0, which introduced objects to the Perl world, came out in 1994 as well.
I think the place where M.J. Dominus goes wrong is in treating the the book is a series of C++ code samples to cut and paste into programs. Bashing design patterns because the Iterator pattern can be, to some extent, expressed using foreach statement in perl is ridiculous. Of course the simple things can be done that way, and picking the simplest pattern in the book makes it trivial to show how. What about the Observer, or Visitor patterns, what about Model-View-Controller? Does Perl have statements for these as well? Can you write mvc $foo $bar $baz->{'fruit'}; and have Perl "do the right thing"? Of course not.
As you start to look at higher level patterns like Acceptor-Connector it's clearer and clearer that they are shorthand ways to describe and name common situations so that programmers and designers can catalogue and pass on their knowledge. Just as carpenters call a particular joint a dovetail rather than describe it's detailed configuration every time, so programmers and designers use Observer as shorthand for a common configuration of components and assignment of responsibilities. Even if the language you're using provides facilities like scheme's excellent macro system you still should know that the Observer pattern is a useful way to organise responsibilites for some situations.
To end in the style in which the slides are written, what sort of person knows so little about Design Patterns as to put forward these arguments, yet feels themselves qualified to present on the topic? On the other hand seeing that on slide 6 Mr. Dominus expresses his opinion that the C++ macro system blows goat dick I think I can make a pretty guess about what sort of person he is.
The Perl community seems to attract this. Sometimes it looks like cleverness and trickiness in coding is valued over intelligence and clarity. Not just in coding though, look at the first Perl Artistic License. The GNU organization says "We cannot say that this is a free software license because it is too vague; some passages are too clever for their own good, and their meaning is not clear."
Posted by Alex at July 17, 2002 08:05 AM
I have to admit I've only skimmed the GoF book, but it did look like it was presented at a level that was only a little higher than 'C++ code fragments to be copied and pasted.' And I don't think that's necessarily a bad thing--a book at that level can be very helpful. One just shouldn't think they know too much about the general idea of patterns and their purpose after reading it.
Or I just need to actually read the book.
(OK, now you post a comment on my weblog, right? Oh no, nevermind. I have been lazy in upgrading to the newest Movable Type, and also I should probably read up on exactly what TrackBack is.)
You said:
Can you write mvc $foo $bar $baz->{'fruit'}; and have Perl "do the right thing"? Of course not.
But that might simply be a defect in Perl. Instead of deriding and dismissing this idea,
perhaps you should consider it more seriously.
Don't you agree that it would be an improvement if languages could abstract away the need for the MVC pattern? That would free up
programmers' attention for more complex and powerful patterns.
You might like to read
Peter Lindberg's thoughts on this matter. I found his approach to this discussion more thoughtful and less reactive than yours.
I hope you find this helpsful.
I may have been a bit reactive.
Design patterns provide a useful common vocab. for programmers to discuss program architecture, design and implementation. This is their main benefit. They should not be regarded as a cookbook of code samples to be copied without thinking.
With the passage of time some patterns, perhaps Iterator is one, become so well known or appear so trivial that the benefit that came from describing them in the first place is forgotten. By analogy, the while loop is now trivial but was a great invention when first described.
If perl is ever to have an MVC instruction or operation it can only come about because someone has first discovered, described and published the MVC pattern and it has become accepted as a useful way to structure the solution to certain design problems. The pattern comes before the implementation, even when the implementation is embedded in a particular language.
Alex, you said that design patterns are not to be regarded as code samples to be copied without thinking. The problem is that the GoF book is mostly about these kinds of patterns, needed in C++ because of its inferior macro system. The inability for languages like it and perl and python and smalltalk and java to abstract at the syntactic level causes large amounts of repetitive code to be written when something clear, simple, and expressive could be used instead, had the syntax been amenable to automated processing. You should see how some of my Lisp code is written. I use some very strange macros to abstract various design patterns I use. See http://linux.rice.edu/~rahul/DefDoc/engine-framework.lisp and look at the with-breaking macro. It's not complete or nearly as general as I will make it later, but this is an example of the pattern coming at the same time as the implementation.
Rahul, you're right of course. A lot of the problems are caused by the lack of macros, or higher order functions. I currently reduced to xslt and code generation to achieve compact notation for some stuff I'm working on. Some things look like they will only be tractable with aspect oriented programming though. Cross cutting concerns such as model view controller may best be expressed this way. btw, I like the lisp
Camps within camps are fighting on this one.
Many people feel Design Patterns are over blown.
I think Arthur J. Riel's "Object Oriented Design
Heuristics" was a much better book. Perhaps it
lacked the prestiegous namesake, perhaps it
wasn't as dumbed down. Within the camp that
thinks Design Patterns are cool, there are those
who think that Patterns are a cool hardcore
object thing, then there are those who believe that the GoF butchered Christopher Alexander's concept of "A Pattern Language". I'm a member of the latter camp. Most Perl programmers don't
use objects because large Perl programs aren't
ever written. To write a large Perl program,
you'd need two Perl programmers (or more),
and no two Perl programmers can read each others
code. Seriously, Perl isn't used for large projects. It has a deserved reputation for
being unmaintainable - so, in one sense, it
despretely needs patterns. In another sense,
patterns won't do a thing for Perl. Being a
hopeless idealist, and loving Perl, I want
Perl to be used for more tasks and to work
to counter its reputation. A liberal interpretation of the idea of patterns lets me
document Perl idioms, object short cuts, hacks
to deal with Perl's OO model shortcomings,
mechanisms for retrofitting structure onto
overgrown programs, integration of object
and lambda programming styles - Perl is a
diverse, introspective language. Depending on
how you define patterns and how you define
need, Perl needs patterns. This problem has
been a real challenge for me - I've worked so
hard on this project, but the interest is just
lacking. The arrogance in the Perl community
is stunning. I think Python is rising to power
not because it is better than Perl - and it some
ways it is, though it shares many of Perl's
weaknesses. I think Python is gaining ground
because of the attitude of the people who write
it. In discussions of OO and Perl, I'll bring
up short comings in Perl's OO implementation -
the reaction is always the same - I must be
some sort of an idiot to suggest that Perl implements method inheritance but not data inheritance - a subclass and superclass can't
avoid namespace conflicts by using a keyword like "private". The fact that people refuse to
see shortcomings is litteraly preventing people
from taking interest in fixing them.
Six months, thousands of hours, hundreds of
pages, and the interest in the Wiki forum
software far outweighs the interest in whats
in the forum. Argh.