The value of patterns

Monday 1 August 2005This is almost 18 years old. Be careful.

Damien takes the occasion of the 2005 Programming Languages Achievement Award to exclaim, “the whole design patterns thing is an over-hyped crock of shit.”

I respectfully disagree, except with maybe the “over-hyped” bit. If you look back at the 50 years or so we have of programming language history, and indeed, the 75 years or so of computer science, a large part of it has been concerned with naming and then studying ever-larger units of computation.

Before Fortran, people wrote programs in assembler. Fortran’s innovation was to say, “If you look at assembler code, there are chunks of instructions in there that are really units. Let’s call those things statements, and make it possible for you to talk about statements instead of instructions.” That was a big step forward.

Algol and its ilk said, “There are chunks of statements that really should be isolated as a new unit, let’s call them functions.” (I know: Fortran had functions, but it didn’t get them the way that Algol got them.)

Simula and Smalltalk said, “There are chunks of functions and variables that really should be considered as a unit, let’s call them classes.” And so on.

To the cynics of the time, none of these steps was particularly interesting. People still write C code where “object-oriented” means a structure and a collection of functions which take a structure pointer as the first argument. They were doing that before OO was big, and they’re doing it now. That doesn’t mean that object-oriented programming (whatever it means to you) wasn’t an important step forward.

Heck, there are people that think Fortran’s innovation of writing statements was no big deal. But most of us agree that it was.

The Design Patterns insight was that collections of classes, and especially the way they interact, are new units that deserve names so we can talk about them explicitly. Is this earth shattering? No, but it can be powerful, and not just because it gives us a shorthand in design meetings. Seeing the interaction between classes as a phenomenon deserving of terminology is an important idea for people designing software. Sure, people have been getting classes to interact for decades, how else would software work? But recognizing this level of system design, and creating a language for thinking about it, reasoning about it, and discussing it, is a big step forward.

Of course, patterns can be ridiculed, and of course, some people will earnestly credit them with solving world hunger, or something equally ludicrous. Just because something is over-hyped doesn’t mean it is unworthy of praise.

I say, “Congratulations and well done” to Gamma, Helm, Johnson, and Vlissides.


I think the problem is that Patterns should have been seen as purely descriptive. A way to identify what you've created, or what you know must be created once you have a firm design in mind. Patterns became confused with programming virtue, and confused with real design.

Many Patterns were also presented as general when they were specific to rigid, statically typed languages. Placed in an agile environment they look crazy and bizarre.
Yeah, but the huge by large difference is that fortran is a LANGUAGE.

And that's where all this pattern stuff belongs. In a language. Not trapped in a book of canned copy and paste Java code.
i googled monkey and saw your drawing. it is so cute it's deadly O___O!!
Uh Oh. Is this another religious argument?

Jeff Atwood wrote:

>And that's where all this pattern stuff belongs. In a language. Not trapped in a book of canned copy and paste Java code.

The Gang of Four wrote most of their sample code in C++, not Java. On the web, you can find plenty of examples of their patterns and more done in Java. I don't know C#, but I think I've seen C# pattern samples on MSDN. That's what is powerful about patterns. They transcend any one language.

On his blog, Jeff included this quote:

>When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough...

When I see patterns in a program, I know the author is trying to communicate something important to me. If he uses Factory, he is saying, "more than one class implements this type and I don't want to bind to a particular class until runtime." That's pretty powerful. I don't see why we need a new language to express an idea like that.

I agree with Ned. Patterns are no silver bullet, but they are a big improvement in the way we think and communicate about software development.
> I don't see why we need a new language to express an idea like that

Indeed, why have new languages at all when we can express a zillion "patterns" in FORTRAN?

Patterns are all well and good, but if you're using a lot of them all the time, what you're *really* saying is that it's time for the language to evolve upward a bit.
>Indeed, why have new languages at all when we can express a zillion "patterns" in FORTRAN?

You seem to be saying that (little "p") patterns and Design Patterns are essentially the same thing. I think they are fundamentally different. Back in the day, I used the "objects in C pattern" Ned mentioned above. We created structs with function pointers and pretended it was object-oriented programming. But we knew it was make-believe. We were stretching the bounds of the language and realizing only a percentage of the benefits of OOP.

Design Patterns, at least in Java, just don't feel like a stretch. We are doing it today without jumping through hoops. Yes, there is a lot of "copy and paste" code as a result, but a new language is a high price to pay to solve that problem.

Language evolution is a process of punctuated equilibrium. You may be right that languages will eventually evolve to handle (big "P") Patterns. Personally, I don't it needs to happen soon and I don't think Patterns will even be the driving force for the next big step. Time will tell.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.