MJD's "Design Patterns Aren't"

I recently went through Mark Jason Dominus' "Design Patterns Aren't" presentation that he gave at an YAPC a while back. I have mustered the effort to write about it here because I think that his slide deck is well worth a look by anyone interested in Perl.

One point that Dominus parenthetically made is that C++ is essentially a 1970's era language, which begs the question why one would use archaic technology. When I write code I want memory management, for example, completely abstracted away. Discovering Perl's capacity for automatically adjusting the size of lists/arrays was a "Eureka" moment for me. Perl abstracts away things that older languages require programmers to code themselves, so in my mind can be considered a more "modern" language than C++.

The main point of the presentation was to bring attention to the work of architect Christopher Alexander, especially his book "A Pattern Language". Dominus illustrates how Alexander's thinking regarding architectural problem solving could be applied to software design problem solving. From the presentation: "The problem Alexander is trying to solve is:
How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?"

Taking a look at your coding techniques from the perspective of a different technical discipline can't hurt...

Comment on MJD's "Design Patterns Aren't"

Replies are listed 'Best First'.
Re: MJD's "Design Patterns Aren't" by brian_d_foy (Abbot) on Jul 13, 2006 at 05:45 UTC
Actually, MJD was more interested in showing how people often mis-interpret Alexander, and that Perl naturally does a lot of the stuff you have to struggle with in other languages. He picks on C++ because the Design Patterns book describes some "patterns" (remember, they aren't) for C++ for things we do in Perl without even thinking about them. Patterns aren't something that you bolt onto a program. It's not about the coding but about the design, which doesn't depend on the language :) -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply]
Re: MJD's "Design Patterns Aren't" by chromatic (Archbishop) on Jul 13, 2006 at 05:04 UTC
One point that Dominus parenthetically made is that C++ is essentially a 1970's era language, which begs the question why one would use archaic technology. Why should it raise that question? Something has to talk to hardware. Now for a system programming language, I generally agree with you. Vanilla (even standardized) C++ is fairly insufficient for high-level tasks. Throw Boost in there and it's somewhat better.	[reply]
Re: MJD's "Design Patterns Aren't" by philcrow (Priest) on Jul 13, 2006 at 14:41 UTC
I think the point of the talk was that the original idea of patterns was to describe a common language for talking about issues that needed resolving, but that that has been perverted by a fixation on particular implementations of particular solutions to the general problems. It's not that we don't have the same problems to solve, just because we use Perl. But, it is often the case the that our implementations are radically different than those proposed by the patterns movement people, and many of our implementations are simpler because of Perl. Which is an ironic indication of how important the general problems are, after all why are there such clean implementations in Perl? Surely not because the general problems are unimportant. The pity is that the patterns idea was subverted into an object only approach to implementations of the named patterns in the GoF book. This is bad not just because the particular implementations in that book -- and in other patterns movement resources -- are not applicable to Perl, but because the focus has shifted from talking about general problems to talking about particular solutions. We happen to notice this shift more, because the resulting solutions are so poorly shaped for our favorite language. Phil	[reply]
Re^2: MJD's "Design Patterns Aren't" by adrianh (Chancellor) on Jul 14, 2006 at 12:23 UTC
The pity is that the patterns idea was subverted into an object only approach to implementations of the named patterns in the GoF book. To be fair I don't think that's the fault of the book or its authors - but the fault of some peoples reading of the book.	[reply]
Re^3: MJD's "Design Patterns Aren't" by philcrow (Priest) on Jul 14, 2006 at 13:14 UTC
To be fair I don't think that's the fault of the book or its authors - but the fault of some peoples reading of the book. Possibly, but their insistence on OO only solutions, even in C++ where others are available, didn't help. It's been a while since I read the book, but I don't remember them presenting multiple implementations for each pattern. They definitely didn't say, "Here's how you do it with objects and here's how you do it without." Don't take any of that to mean I don't respect their book. I learned a lot from it. In particular the problems they are trying to solve, and their descriptions of them, have greatly improved my skill in medium to large scale design. I just reject their school of thought when it insists on OO only and their followers when they insist that any implementation of a solution to one of the GoF problems must mimic the one in the book. Which leads back to your point about the people reading the book, who certainly must shoulder a lot of blame. Phil	[reply]
Re^4: MJD's "Design Patterns Aren't" by adrianh (Chancellor) on Jul 16, 2006 at 14:15 UTC
Re: MJD's "Design Patterns Aren't" by jdporter (Paladin) on Jul 13, 2006 at 14:17 UTC
...begs the question... Ehh... Begging the question ...why one would use archaic technology... You mean time-tested, proven technology? I can't imagine. Perl abstracts away things... Quoth Larry Wall: If you want to program in C, program in C. It's a nice language. I use it occasionally... :-) We're building the house of the future together.	[reply]
Re^2: MJD's "Design Patterns Aren't" by Aristotle (Chancellor) on Jul 15, 2006 at 14:02 UTC
You mean time-tested, proven technology? I can’t imagine. Reminds me: “Legacy (adj): an uncomplimentary computer-industry epithet that means ‘it works’.” —Anthony DeBoer Makeshifts last the longest.	[reply]
Re: MJD's "Design Patterns Aren't" by zakame (Pilgrim) on Jul 15, 2006 at 13:33 UTC
The last paragraph reminds me of Fred Brook's description of Saint Remi Basilica in Reims France, in The Mythical Man-Month ... now that took a looooong time to build (around 8 centuries to complete,) but nontheless the conceptual integrity that was inherent in the original design remained well into today. I suppose one has to look beyond the language; one really has to look outward, recognizing patterns beyond what we do recognize as patterns now, and stand in awe at those big things we are missing...	[reply]