John and I used to work together, and we developed a reasonably large code base. Here are three software patterns I've noticed in the Lisp code we have.

1. Subclassing CLOS objects to include a synchronization lock, and then using CLOS CALL-NEXT-METHODs on the definitions of the subclassed objects.

2. Providing 'encapsulation' with packages; using DEFPAKAGE with uninterned symbols as the way to avoid case conflicts.

3. Providing system definitions in a certain way and file structure. (X.system defines the X system; this (probably) has DEFPACKAGE forms in it as well as system definitions; LOAD-X.lisp loads or compiles the system.

In many ways, these examples indicate patterns that get around some limitation of Lisp. If Lisp had (in the core language) something like Java's SYNCHRONIZED keyword, (1) would be unnecessary. If Lisp had a better package system, (2) would be unnecessary. If Lisp had a standard system definition facilty, (3) would be unnecessary.

Yes, though GoF-style patterns might not neccessarily be a good representation of the general idea of design patterns, I've thought people have sometimes been too quick to dismiss the utility of patterns a lot like them in Lisp.

I think the often heard response that goes something like "Design patterns are macros in Lisp. What's the big deal?" isn't very helpful, or accurate, as your examples begin to suggest.

More Richard Gabriel[1]:

"Here's another true statement about patterns: If there are no such things as patterns in the Lisp world, then there are no statements a master programmer can give as advice for junior programmers, and hence there is no difference at all between an beginning programmer and a master programmer in the Lisp world."

"The GoF patterns are notorious in parts of the patterns world for misrepresenting the patterns concept because they provide to C++ programming constructs we have in Lisp. The authors of the book understand that - they are as smart and knowledgeable as you all think you are - but maintain that the poor C++ programmer needs these patterns, which is true."

[1] http://groups.google.com/groups?selm=B823F0D4.1387%25rpg%40dreamsongs.com

In retaliation, I commented over there too.

And now I'm back here to reply to that comment. GoF isn't the be all and end all of pattern books obviously. Perhaps the code samples are a distraction, personally I've never read them, not much of a c++ person myself. Also, if you know all of the techniques/patterns it describes and read the book expecting something new you'll be let down. On the other hand, I think people should know how to "Provide a unified interface to a set of interfaces in a subsystem." The Facade pattern is one way to do this: "Facade defines a higher-level interface that makes the subsystem easier to use". Perhaps designing by picking patterns for the less critical or more well understood parts of a system at least initially lets you concentrate on the more complex bits.

The biggest benefit to me though is the shared vocab for talking about programming and design.

Uh, what's with the goat?

Go to the 6th slide, then click "Next".

Goats are cute.

http://www.pobox.com/~mrh3/mompix/goatling.jpg

To be fair to the GoF book, although many of the examples are in C++, some are in Smalltalk which (I take it) is loosely typed. And the GoF guys do talk quite a bit about the extent to which certain patterns are changed or become unnecessary if compile-time type restrictions go away. (I've never done any Smalltalk programming myself, and so found the Smalltalk code samples incomprehensible. Smalltalk seems to be the next contender after Lisp for the programming-language "inspiration of zealotry" award.)

I do think that it's a really helpful book, and agree that the shared vocabulary is the most important part of that. The (C++) codebase I see most often these days has a lot of comments using that vocab, and it's hard to imagine how those descriptions would have been done without it.

By the way, for my old CBR friends, check out these sentences:

"One thing expert[s] know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts."

Schank, Kolodner, Hammond? Nope, GoF. :) (Of course, their whole mission is to turn cases into really good prototypes, so that even the experts don't need the cases anymore.)