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.

But, patterns by themselves are neither interesting nor generally useful. A
pattern is part of a pattern language, which is a coordinated set of
patterns that tell you how to build a really nice artifact of a particular
category customized to your needs. If you are someone who thinks that a
pattern is just an abstraction or is something that a great abstraction
mechanism can provide for you, then put that thought firmly in your head
right now.

Here are some remarks about a pattern language for spreadsheets. By a
"spreadsheet" I mean any sort of constraint satisfaction system that relies
on geometry to provide intuitive assistance to its users who use and
sometimes program the spreadsheet using, perhaps, a user interface. The
design of the "macro language" is part of the problem of designing and
building the spreadsheet. A spreadsheet pattern language is aimed at doing
two things: It teaches how to create such a system, and it teaches what
makes a good spreadsheet for users and for programmers who have to build and
maintain spreadsheets.

It starts with a tour of what a general spreadsheet is in the form of a
skeleton of the steps you would take to write one. You would use this PL if
you needed to write a spreadsheet program for a particular application or
for a particular set of users with oddball needs. Its patterns would tell
you at every stage of the process what to build (code or design) next. If
you were an expert programmer but had never done a spreadsheet before you
would be able to build a nice one the first time, and at the end you would
understand how to build anything that was like a spreadsheet - perhaps with
the assistance of the pattern language.

The patterns and pattern language are a stylized way of presenting the
information you need, and each pattern includes the reasons why the thing
you build using the pattern makes it nicer for you as designer/coder and for
the person using the spreadsheet.

You *could* substitute for this some mondo set of abstractions and macros
and a framework for generalized spreadsheets along with some documentation
for it, but the pattern language is more general and in the end it teaches
you about the art of creating spreadsheets. And, in languages like C++,
Java, and SmallTalk, you could do the exact same thing, yet many people
prefer to write pattern languages, mostly because of the pedagogical angle.

Again, if you think patterns are only about abstractions, then you must
notice you never comment to yourself that one piece of code is better than
another nor that one design is better than another. Patterns are a literary
form for expressing those judgments along with the reasons why, and a
pattern language is a literary form for showing and teaching people how to
build a nicely designed and implemented system.