Design Patterns == weakness in language

[Steve Horne]

On Sat, 16 Sep 2006 09:29:38 +0200, renox <renosky at free.fr> wrote:

>The claim is that "16 of 23 patterns have qualitatively simpler 
>implementation in Lisp or Dylan than in C++ for at least some uses of 
>each pattern" which is a very different that claiming that design 
>patterns are unnecessary.

23 patterns?

The GOF book has precisely 23 patterns. So presumably, the logic is
that this set of patterns is definitive and they are the only patterns
that exist...

We must bow down to the most holy gods of GOF!

We are not worthy!
We are not worthy!

I haven't laughed so much in ages!


Just to add to your criticism...

There are thousands of widely recognised published design patterns,
encoding experience from a variety of fields - not just OOP. There are
database design patterns for instance. There is this thing called the
Portland Pattern Repository. There are 'pattern languages' for people
who need a standard way to express patterns. There are even
antipatterns - spelling out bad experience so that it can be avoided.

Personally, I've found Martin Fowlers website to be a useful source of
design patterns (and some very interesting papers besides).

http://www.martinfowler.com/

The GOF patterns are meant to be widely applicable, of course, and
they are in so far as a whole bunch of imperitive object-oriented
languages provide similar kinds of semantics. But that's exactly it.
They specifically say that they are for "standard object-oriented
languages" right there on xi of the preface. And Smalltalk, Java and
UML were particularly in mind throughout.

The GOF patterns were mainly intended as an introductory set to
illustrate the principle and get the ball rolling. The 23 GOF patterns
cannot be treated like the 10 commandments.

So Lisp makes some Java patterns look a bit daft. So what? Lisp and
scheme and such have their own patterns and, shock horror, many of
them make no sense in Java or C++.

Learning to use any language goes through a number of stages. The easy
bit it getting used to the syntax and semantics. The hard bit is
adapting your style - finding the patterns that work. I've done the
easy bit maybe a hundred times. The hard bit, maybe ten. I couldn't
get on with Scheme last time I tried - no problem with the syntax or
the semantics, its all a matter of having the patience to figure out
the patterns that work.

One of the explicit goals of design patterns is to standardise common
ideas that have arisen out of experience, and to provide names for
them, so that it is easier for experts to answer "how do I" style
questions.

Novice lisp programmers have been saying "How do I" for a long time.
There's lots of standard answers to common questions of that form,
answers that go well beyond the realm of syntax and semantics and into
the realm of design patterns. There are more design patterns in Lisp
than any reasonable person could attempt to count.

If a design pattern is a language deficiency, then Lisp is a seriously
deficient language.

Personally, though, I think David and his references just don't know
what a design pattern is. They are taking the idea of the GOF book
being a bible too literally. It's not about the word of the four
design pattern gods. It's about collecting design experience and
making it accessible.

There may be some resistance to collecting the design patterns for
Lisp, or at least using the name 'design patterns' for them. That term
is, after all, very young compared with Lisp - the Lisp 'culture'
should be expected to be a bit set in its linguistic ways, and if
terms like 'FAQ' and 'how to' have served well for so long, why
change? OTOH, It may be that I just haven't found such lists.

The design patterns are out there, though, and if someone would
actually collect that knowledge and make it accessible it would be a
good thing. It would make it a lot easier to learn to do real work in
Lisp/Scheme/whatever for a start. Then maybe I wouldn't just forget it
again after the first month or so, turning back to the more familiar
imperitive/OOP patterns that I've used so much for the last 20+ years.

Plenty of languages have influence how I think and inspired new
patterns and approaches, but for me, Lisp isn't one of them. Syntax
and semantics, sure, but no paradigm shift. And the holier-than-though
attitude that happens a lot tends to bug me. I mean, why start a
thread like this in the first place? If your so into Lisp, fine, use
Lisp. I'm all for advocacy, but... Well, there's good advocacy and
theres bad advocacy...

http://www.perl.com/pub/a/2000/12/advocacy.html

There's tongue-in-cheak advocacy...

http://dave.org.uk/talks/advocacy.html

And, well, there's being a prat.


Now - if I went over to a Lisp newsgroup and said "so, this Lotsof
Infuriatingly Stupid Parentheses language of yours, I reckon its a
load of crap. Here are my badly thought out reasons." then that would
be me being a prat.

But I'm busy ordering pizza right now - maybe tomorrow.

-- 
Remove 'wants' and 'nospam' from e-mail.