Monday, 8 July 2002
Eric points to another Mark Jason Dominus talk, this one with a basic premise that design patterns wouldn't need to be explicitly coded if languages had better macro support, and that there's more to be learned from Alexander's work. Seems reasonable.
I've spent a reasonable amount of time on design patterns in several classes and seminars with Ralph Johnson, who teaches here. I've never read Alexander's A Pattern Language or any of his other books. Patterns aren't magical, but for me, I get three basic things out of reading pattern work:
- Learning how people solve problems in their native application domains gives me ideas on how to solve analagous problems in my own work. Books that focus to a certain extent on idiom, such as parts of O'Reilly's Cookbooks or Smalltalk Best Practice Patterns, are similar, except the domain is the mechanics of the language itself.
- Learning how people categorize strategies. Very seldom in my experience will I use a pattern exactly as it's specified, unless it's something simple (in which case, like iteration, it'd be built into a language or library). Taking pieces from mutliple patterns is a bit like mixing metaphors: it's something that works sometimes, but it's a lot less embarrassing if the mixing is deliberate. When my code is full of inadvertent spoonerisms, the result is not only embarrassment, but major architectural problems later on.
- Learning the nomenclature. Like Eric, most of the patterns in the GoF book I had seen, if not used, before in my own code. It helps to have a common vocabulary when discussing architectural issues with others, or even reasoning about them myself. It's also somewhat reassuring to know that someone, somewhere, thought that whatever you're working on is important enough to give a name to.
Note that none of these benefits involve cranking out repetitive C++ or Java code. I certainly prefer to use languages with more syntactic flexibility, but where you can do what you want without having to remember too much syntax or too many rules. This means Lisp/Scheme, Smalltalk, Objective-C, but not Perl, Python (too much to remember), Java (too inflexible), or C++ (both).
I see the elegance in Perl, but I'm not willing to give my life over to it: I have too much work to do which doesn't lend itself to Perl. The great thing about Smalltalk, for example, is that a lot of its elegance comes from idiom and library design. You don't have to be aware of everything initially; you can blunder ahead, reading source where necessary, reinventing wheels, and still get work done, maybe doing things the hard way, but constantly learning so you do better next time. With Perl, of course some of this applies as well—you can write it like C if you want—but it turns out that in any given Perl project I attempt, I'm always fighting the language until I have anything but complete mastery of the subset I'm using. Then i go away for six months, forget it all, and have to start all over again.
3:37 PM
