Slashdot Mirror
'Design Patterns' Receives ACM SIGPLAN Award
bth writes "ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
As mentioned by Paul Graham, in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.
http://www.thebricktestament.com/the_law/when_to_
Congratulations to the GoF. Their observations of patterns of systems and behavior are well-described and well-cataloged in their book. I only wish the concepts and materials were conveyed better when taught.
Most of the time people start with the attitude "Let's start with the Visitor pattern" or something like that. The point of the patterns movement is there are common things that are done, wouldn't it be nice if we could talk about them with common terminology and use the full richness of our experience to ensure when we see the problem again that we don't make all the same mistakes we made last time.
I'd like to see it taught (and this can be in the programming shop, too) like this: "What are we trying to do? Where have we done something like this before? Doesn't this look like something we've done last month? Can you detect a pattern to all this?!"
Instead, what I often see if people spouting pattern names like one would name-drop at a party--the more you drop the more important you must be. Starting with the problem to be solved, the understanding of same, and then recognizing that we've seen this before, then naming the pattern is less flashy but is more the intent of the GoF IMHO.
Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup of the issue. Paul Graham also has an interesting take on this subject.
A deep unwavering belief is a sure sign you're missing something...
Programming paradigm. It's the most appropriate word to describe the different families of programming styles/languages: procedural, functional, object-oriented, imperative, logic and such. It's commonly accepted; I've seen it in places ranging from textbooks to CS papers to Stroustrup's C++ book.
Seriously. I think some patterns are fine for some things, but as a previous poster has stated, more ugly-as-shit code has been written using design patterns than not.
I know that in the OO languages world, this book is hailed by many as the holy book, but to me, there really is only one... "Code Complete".
The one book teaches the fundamentals of good programming *in any language* better than any programming book ever written.
Case in point, I don't think any shit code has been written as a result of applying the techniques and best practices in "Code Complete". I certainly can't say the same about "Design Patterns".