Design patterns aren't | Hacker News Reader

Design patterns aren't

perl.plover.com

69 pointshenning30 comments

In his postscript the author explains that he wasn't trying to criticize design patterns, but was rather trying to promote this other concept; which, supposedly, is little known in CS circles because of the similar names...

His summary: "We need to take a fresh look at Christopher Alexander."

That's all well and good, and as far as I know the concept of pattern languages could be very useful; I wouldn't know, I've never heard of it till today, and in fact still have no idea what it's about. Which brings me to my point, which is to wonder why the author chose to waste an entire 5 minute and 13 slide presentation (5 of which were dedicated just to bashing design patterns) to making the point that "we need to take a fresh look at Christopher Alexander," instead of, say, spending more time introducing Alexander's ideas and presenting ways they could be useful in our domain.

I will conclude by pointing out another pet peeve of mine, which is sensationalist titles only tangentially related to the content. Design pattern, most certainly, ARE. What they are NOT is pattern languages, which is a similar sounding but entirely different concept.

</ grumpy geezer mode>

There was also a great discussion about this on Stack overflow: http://stackoverflow.com/questions/327955/does-functional-pr...

TL;DR: Gof had in mind C++ and Smalltalk. Some languages eliminate the need for many of the patterns in GoF, and they don't eliminate the idioms (patterns for a particular language), as they barely cover it.

Another good info on the subject is this presentation: http://www.infoq.com/presentations/Functional-Design-Pattern...

I'd recommend going over the postscript http://perl.plover.com/yak/design/samples/note.html and note that all the discussion here has already happened years ago. IMHO if the majority of listeners misunderstand your talk and don't get the point you're trying to make, then you made a bad talk. Seems like his real point was to distinguish between the GOF book and the Alexander book were about. That's great. Present that point in a thoughtful and careful way, not by going off on GOF in a way that will turn off listeners/readers and occlude the more subtle point you're trying to make.

Not the majority of his listeners but some hard to measure fraction of those who read his slides online without the context of the talk that he gave.

Yeah, it's definitely not a good set of slides unconnected to the talk. He even admits that.

"IMHO if the majority of listeners misunderstand your talk and don't get the point you're trying to make, then you made a bad talk."

Does not follow. It is also possible that he has made a hard point, which the brains of the readers have a hard time representing with their internal conceptualizations, therefore misunderstand, then act on those misunderstandings. I think the presentation is perfectly clear, and do not see any obvious way it can be made wildly easier to understand.

Quality of communication is not just bounded by the quality of the sender, it is bounded by the quality of the recipient as well. The point this presentation is trying to make is intrinsically hobbled by the fact that many people cognitively will only perceive something that boils down to "PATTERNS GOOD" (hooray!) or "PATTERNS BAD" (boo! flames!), and "PATTERNS DOGMA A LOSSY TRANSLATION OF SUPERIOR ORIGINAL PATTERNS CONCEPT" doesn't into either of those buckets very well (the distinction between patterns dogma and patterns idea being a tricky one all by itself), and if that's how one approaches it, it's easy to see how it simply falls into the "bad" bucket.

When I read the GoF book in '95 it was a revelation, I had learned C++ a few years earlier and here were all the things I had seen in my and other people's code with names and explanations. At the time Rogue Wave hosted an informal lunch meeting in our town where they and some OSU guys discussed patterns, I attended as a visitor and to me it just seemed magical. Over the years some of the high hopes have been dashed but I think some of the core pattern ideas have become useful standard idioms.

A year or so after reading the GoF book I saw the Alexander book in a used book store and picked it up to see what it was all about and I was very surprised. I like the book a lot but I really don't think the parallels with the GoF book and the software design patterns are all that strong. The Alexander book does not seem very systematic or analytic, it's more rambling and philosophical. I'm not an architect so I probably don't see the big picture but to me the book seems to lack a coherent vision.

If you're interested how Alexander himself saw himself fit into the emerging pattern movement, here's a link to James Coplien's description of Alexander's OOPSLA appearance in '96: https://sites.google.com/a/gertrudandcope.com/info/Publicati...

Hard to believe it's been 15 years!

paraphrased: "In C++/Java, you write an iterator again and again for every collection"

No, you don't. If you write them yourselves (which is in most but all cases the wrong approach, what with the Java libraries and the C++ STL), you use templates or generics, as appropriate, to define reusable ones.

In many cases, proper patterns are reusable--and in many cases for good programmers, design patterns occur automatically just because they're a logical way to do something. I don't set out to create flyweight objects, they're the simplest way to achieve my goal. I don't write a thread pool just to create a thread pool, I write a thread pool because it makes sense.

Even in 2002, this was the case. I don't get the feeling that the author of these slides knew either well enough to make the claims he made.

The Gang-of-Four idea is to discover existing patterns of software development / Then program people to implement them habitually

Er...no. The book Design Patterns is descriptive, not prescriptive. Is that so hard to get?

I am by no means a C++ fan, or even really a GoF fan, but this post is slagging it just to slag it. If you want to slag it after you understand it, by all means (and I have perturbed a great many electrons in doing so, myself), but it doesn't sound like the author does, at all.

Have you read anything by Alexander?

I haven't, but I'm not looking at what he says.

I'm looking at what appears to be the author of these slides, taking a very strong point about something about which he demonstrates little knowledge. No, the GoF stuff isn't the same as what (it seems like) Alexander is saying. That doesn't make it wrong, and it doesn't mean this author isn't misrepresenting the GoF in the linked work.

The GoF, are not the Design Pattern Police, demanding that you tack Strategy and Command and Memento objects everywhere. It's observational material based on seeing many people reinvent essentially the same wheel over and over again.

http://perl.plover.com/yak/design/samples/note.html

He didn't want to criticize the GoF book. He wanted to say that C++ and Java suck because they need Patterns. PG also said as much. Quote from the link above :

> I am not saying "design patterns" are a bad idea. GoF-style design patterns seem to me to be an interesting and valuable idea, worth studying and developing. Even in their least interesting form, people do need to work around the severe deficiencies of C++, and if "design patterns" help them do that, it's a good thing.

I don't understand how design patterns can't exist in any language. I'd even argue its the existence of design patterns that make programs readable at all. I can look at code and say, "ahh... case analysis."

That would be because they (obviously) do exist.

This comes off as people strangely perturbed about the popularity of Something They Don't Like to me. (Paul Graham's own comments on the matter included.)

> That would be because they (obviously) do exist.

Spot on. Now what? Well, you could for instance ensure that the most common patterns are as readable as possible. Most of the time, that means adding special support for them, or let the user write such special support.

Case analysis, for instance, is a pattern. Now you can implement it with nested `if`, or you can use a `switch` statement (if your language has either `switch` or macros). Personally, I prefer the `switch` statement, which at a glance makes clear what pattern is used.

GoF patterns are useful. The shame is C++ and Java's inability to properly implement them. Really, if you often use mixins, maybe you need closures. If you often loop over data structures, maybe you need `map` and `filter` (as closures or special syntax). And so on.

GoF patterns don't suck. They just highlighted how much C++ and Java sucked, by showing how much copy-paste you have to perform. In an ideal world, patterns would only be instantiated once: in the compiler or in a library.

On a related note, here is why I think C++ and Java suck, badly: http://www.loup-vaillant.fr/articles/classes-suck

You get map/filter/reduce via boost pretty easily, though.

I can look at code and say, "ah, Alan Perlis, you were right when I read your advice when I was 11 years old, but did not understand your wisdom [1]":

10. Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

[1] http://www.cs.yale.edu/quotes.html

Few sensible C++ developers in 2002, let alone earlier, could or did use STL iterators, generics, or templates on a large scale. Yes, they all technically existed, but it wasn't something you'd put in production code yet. The ideas and prototypes were a few years old at that point, but the shipping libraries were very new, and if you were trying to write cross-platform you couldn't count on them existing at all.

Maybe my team wasn't sensible, but the main reason we were using C++ in 2002 was for the reasons you described. We admittedly weren't cross platform, but we found the features compelling -- and while maybe not as stable as we'd like -- still more stable than most JVMs that were all the rage.

Same here. I was writing C++ with templates and the STL in 2002.

Of course, I was also 14 years old and working alone on toy projects, so I didn't have to worry so much about any of that. ;-)

> Few sensible C++ developers in 2002, let alone earlier, could or did use STL iterators, generics, or templates on a large scale

This may be far too much of a generalization. The team I worked in was making heavy use of templates by about 1999. Now it was true that no compiler implemented the full standard and you often needed workarounds. But many developers clearly saw the utility and made use of the fact.

That is simply not true for 2002. Maybe for 1995, but then again, what did we have in 1995? Even Java was only released in 1995 according to Wikipedia - even in 1999 it was still a hot new thing that was mostly used by early adopters.

I think the criticism here on GoF is misdirected.

As far as I'm concerned, GoF is (or at least should be treated as) a taxonomy, not a cookbook.

The fact that people use it as a cookbook is not necessarily the fault of the authors.

Agreed. The GoF's stuff is descriptive, not prescriptive. You'll always get the occasional zealots going "no no, you must slather your code in Servants and Visitors", but...they're not the GoF, and who cares what they say?

The GoF value isn't in being a taxonomy. It's about noticing that given certain environmental conditions and a goal, people will derive similar solutions. Patterns are just time-savers. So, if you see X, then do Y, because it will just work.

That's pretty much what Alexander's books say.

The failure of GoF, in particular, is that people took it as a golden rule for every environment. IIRC, the examined source code was all object oriented c++ and smalltalk code. Yeah - it's not surprising that those patterns aren't going to work well in, say, Haskell.

| The failure of GoF, in particular, is that people took it as a golden rule for every environment

Back in the days of C when assembly was still important, calling conventions represented patterns that ensure the stack got cleaned up properly. We may no longer talk about it, it is still there, doing its work silently. The design patterns were harvested from a language that didn't support lisp-style macros or continuations or closures.

Patterns are helpful for people who have to work with particular languages, but are not particularly useful to language designers. But then, they [language designers] already know that.

True, they won't work everywhere that well. There's another presentation from Peter Norvig: http://norvig.com/design-patterns/ppframe.htm

It has a lot of examples which fold into one liners in dynamic languages or are simply "the way it could be done" instead of a pattern (they don't require additional code or attention - see abstract factory).

DSL FTW?

The article/presentation seems to imply the benefit of domain-specific languages for capturing the software requirements (which is what Alexander's "Pattern Languages" sounds like to me).

How to properly create and re-use DSLs sounds very much like an artform to me...

I thought of that as well, but the reach of the idea goes a long way past DSLs. It definitely applies to programming language construction in general and to almost anything you can do with computers.

Find the right abstractions that gives you the right amount of details while at the same time give you the tools to scale your reasoning about a problem, and you can move mountains. Find the wrong balance, and you will end up with a cluttery hell that is impossible to maintain or a blunt tool that doesn't do anything well.

The critique of GoF presented is superficial. The main difference being GoF's 'how' against Alexander's 'what' doesn't come from GoF's misunderstanding of Alexander's original work. It comes from a different role of architecture of a building versus an architecture of a computer program. It's easier to say about Alexander's pattern that it provides an answer for a 'what' question because the building's architecture is something that people interact with directly with all their senses. Hence a pattern like "159. LIGHT ON TWO SIDES OF EVERY ROOM" ( http://www.patternlanguage.com/apl/aplsample/apl159/apl159.h... ) seems like an end in itself when compared to eg. a iterator pattern, which obviously always will be described merely as a mean to some more general functionality of the application.

The truth is, "LIGHT ON TWO SIDES OF EVERY ROOM" is also a mean - a mean to making a room more bright, pleasant and friendly . If it feels more substantial than an iterator pattern, it's just because we directly interact with an architecture of a building in contrast to the architecture of a software, which is always hidden.

There's nothing wrong with GoF, it just follows from the essential quality of a computer software.

What, is this not how we've been using design patterns all along? I always used these patterns to simplify the explanation of how the architecture should or could work. I've never referred to some master cheat sheet of patterns I can copy and paste into my source code to save time, you generally need to custom fit your solutions to the problem at hand.

Sounds like the Ubiquitous Language idea from Domain Driven Design is a closer analogue. I haven't read Christopher Alexander's book so I'm just going on the article's summary.

http://domaindrivendesign.org/node/132

Reply on news.ycombinator.com