Scheme Patterns???
Gregg Reynolds
Well, I discovered Scheme about a year ago, thanks to DSSSL, and I
confess I have gone bonkers over it. For this liberal arts major who
entered programming through the back door and always felt vaguely
embarrassed about instructing machinery for a living (it somehow smacked
of auto mechanics, or welding), Scheme has been an absolute revelation.
(Understand: they made me learn Cobol (sob!) in my first job.) When I
first came across those fateful lines in SICP ("... computer science is
not a science ... its significance has little to do with computers ...
the emergence of what might best be called 'procedural epistemology'") I
got so excited I almost strangled my cat. Not only a new way of looking
at things, but, even better, a new and impressive-sounding title for the
business card! I'm no longer a mere programmer, I'm a Procedural
Epistemologist! Make that $250 an hour, please! (wishful thinking.)
Unfortunately, the people I work for, somewhat lacking perhaps in
theology and geometry, seem to be more preoccupied by such mean
irritants as fixing bugs, meeting deadlines, etc. So I'm left to
conniving (pun intended) to use Scheme at work, where C rules, and the
boss loves Perl. So now that I've had my outburst (look for my book of
Scheme poems, "O Lambda, My Lambda!", Real Soon Now) here are some
questions I hope somebody here can answer.
I've found quite a few websites with lots of useful Scheme stuff, and
I've acquired nearly the entire printed library, but there are large
chunks of Schemedom with no useful commentary and/or guidance that I
know of. I'm thinking here of two issues: one concerns the "advanced"
parts of basic Scheme, such as macros and continuations; the other
concerns what might be called patterns in Scheme. The latter I would
subdivide into two areas, one covering specialized and well-defined
'idioms' and techniques, such as pattern matching, modules, OO stuff,
etc; the other covering more general issues of Scheme practice and
style, such as when to use "collectors" (a term I have only seen in "The
Little Schemer" but which I assume has more widespread use; true?), how
to organize code, and so forth. Numerous "design patterns" books have
appeared using C++ as the example language; not too long ago a volume on
Smalltalk patterns came out. I'm looking for this kind of stuff in
Scheme; it would be especially useful, since there are so many ways of
doing things in Scheme.
I'm aware that there is some info on many of these topics, but often it
is sparse and fairly technical. The pattern matching library that comes
with DrScheme is a good example. It looks very interesting, but the
doco is entirely reference techospeak; I need examples and discussion.
Can anybody help with pointers to tutorials/guides to such things? I'm
particularly interested in learning how to use continuations shrewdly,
pattern-matching treacherously, and text-processing ruthlessly.
Remember, I've got to out-pearl perl.
Thanking you for your indulgence,
I am
your faithful
unindicted co-conspirator,
Gregg
--
Will Hartung
Gregg Reynolds <gre...@mcs.com> writes:
<enlightenment path, snipped>
>So now that I've had my outburst (look for my book of Scheme poems, "O
>Lambda, My Lambda!", Real Soon Now) here are some questions I hope
>somebody here can answer.
Oh, jolly good. Put me down for a copy. Actually, wouldn't a "Scheme
poetry" contest be an interesting coralary to the "Obfuscated C"
contest (though I think I've seen Perl Poetry somewhere before).
>I've found quite a few websites with lots of useful Scheme stuff, and
>I've acquired nearly the entire printed library, but there are large
>chunks of Schemedom with no useful commentary and/or guidance that I
>know of. I'm thinking here of two issues: one concerns the "advanced"
>parts of basic Scheme, such as macros and continuations; the other
>concerns what might be called patterns in Scheme. The latter I would
>subdivide into two areas, one covering specialized and well-defined
>'idioms' and techniques, such as pattern matching, modules, OO stuff,
>etc; the other covering more general issues of Scheme practice and
>style, such as when to use "collectors" (a term I have only seen in "The
>Little Schemer" but which I assume has more widespread use; true?), how
>to organize code, and so forth.
I would consider these all "idioms", rather than "patterns",
personally.
>Numerous "design patterns" books have appeared using C++ as the example
>language; not too long ago a volume on Smalltalk patterns came out.
I haven't looked at many of these books. The only "patterns" book I
picked up was one relating to higher level application objects.
Because of its expressiveness, Scheme is in great need of a collection
of idioms. One problem though, is that when an idiom becomes prominent
enough, they have a tendancy to become "macros" :-), especially if
they are at all even mildly verbose. When they become macros, the
idiom is gone. The point of the idiom is to make the operation clear
just by its general form. If someone is writing a filter or a
collector or whatever, and they use a "common idiom", a reader can see
that the program is filtering or collecting something in someway,
without having to know the specifics immediately. By looking at the
form of the operation, the idiomatic bits stands out while the details
can be ignored until needed later.
If, however, the idiom has been macro'd, then, perhaps, the general
intent of the operation is clear only by the name of the operation. If
the name is unknown to the reader, then the process being represented
is immediately opaque until the reader hunts down the macro definition
(or function definition).
Clearly, there is a fine line to be drawn between never using higher
level functions and macros to always using them. In Common Lisp, there
are so many different forms, macros, and functions, that they are
almost always used. As a CL reader, you need to make yourself aware of
the CL vocabulary to get a better understanding of the code your
reading. Once you know your CL vocabulary, CL becomes comfortable to
read.
In Scheme, the vocabulary is very small. You want to rely on idiomatic
program structure to convey high level meaning to the code you're
reading. We do this is C all the time. Since C has a limited and
non-extensible syntax, you must rely on idioms to communicate
algorithms and structure.
The issue in Scheme is that since you have a limited vocabulary, but
can very easily extend the syntax, each program of size can become
it's own little world. Local macros, creating local idioms. A new
reader must learn these new structures and operations before they can
become comfortable with the code. This CAN make Scheme code (and, of
course, to a similiar extant CL) uncomfortable for a new reader,
especially a novice reader who has problems seeing the similarities
from one program to another.
When learning, we tend to copy what we see and what we're taught. When
we look at new code we search for the stuff "we know", the stuff that
pops right out of the screen so that we can get a running jump on how
something works. When we look at some code that is idiomatically
different, then all of a sudden you're back to the level of CAR and
CDR versus looping, filtering and collecting, and the program becomes
that much harder to read and understand. As we become more
experienced, we learn more and more idioms and techniques.
It is said that to learn to write really good code, you need to read
really good code. From doing that we can learn the idioms of simple
looping, collecting, whatever, on up to idiomatic module structure,
inter-module communication on through the whole program design.
I can't provide any sources, but I feel that Scheme is in dire need of
some idiomatic collection because in some ways, it can be a bit TOO
flexible.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Gregg Reynolds
Will Hartung wrote:
>
|>
> Because of its expressiveness, Scheme is in great need of a collection
> of idioms.
Will, that was one terrrific piece of writing, a gem! You really should
work that up into something publishable! Very clearly presented way of
looking at such issues that I hadn't considered before; you've given me
plenty of food for thought. Also, it has a nice "essay" tone.
I agree, "idioms" works better than "patterns". It nicely places focus
on the "language-ness" of programming, in contrast to the many metaphors
and figures (e.g. "design patterns") in vogue now that are borrowed from
architecture, and which tend to make me at least a little uneasy.
Regarding a collection of idioms, I wonder if anybody out there has room
on a Web site for such a collection. I'm thinking of a web equivalent
(in form at least) of Knuth's Stanford Graphbase, which is a collection
of little literate programs in C. Of course it needn't be restricted to
such content; I only cite that as an example. Such a site would consist
of a collection of webpages rather than a repository of code, with
content to be provided by anybody who wants to contribute. For example,
in working on a Scheme-based literate (or meta-) programming tool, I've
got 3 or 4 idioms involving practical uses of collectors in text
processing that I'll be writing up for my own notes; it would be fun to
be able to make such stuff available to others climbing the mountain.
And even more fun to have a single point of reference/info to turn to
when facing new problems. (Which reminds me, I'm still looking for
practical, useful examples of pattern matching.)
For an example of what can be done along these lines goto the DSSSL
Documentation Project at http://www.mulberrytech.com/dsssl/dsssldoc/.
Thanks again for your terrific response
Gregg
Thant Tessman
"Scheme Patterns" strikes me as a contradiction in terms.
"Design Patterns" are a phenomenon of traditional object-oriented
programming languages, not languages like Scheme. The reason is that
traditional programming languages just aren't that expressive--they only
support well the abstractions built directly into the language.
Consequently, there are many common tasks that require a lot of
elaboration. Searching for design patterns is simply an attempt to
formalize the elaboration necessary to support abstractions not directly
supported by the language.
By contrast, a language like Scheme supports far more than any
tratitional language the ability to write programs that write programs.
In a sense, it's a programming language good for building programming
languages. This makes it easy to introduce new abstractions in a way
that makes them look and feel like they were designed into the language
from the start.
So when using a programming language like Scheme, as soon as you
recognize a "design pattern" you write something to automate the
expression of that pattern. And then you move on to something else.
-thant
Joseph Allen Dane
Thant Tessman <th...@bogus.acm.org> writes:
> "Scheme Patterns" strikes me as a contradiction in terms.
>
> [ ... ]
>
> -thant
I agree with this, but I don't think it takes into account the very
good point that Will Hartung has made: that the expressiveness of
scheme can make scheme code somewhat impenetrable to outsiders. With
sufficient effort, of course, a reader unfamiliar with the
abstractions used could figure it out, but if the code used conventional
idioms things might be a bit easier. Which isn't to say scheme needs
to be LISP, only that there are, uhh, "patterns" which pop up all the
time and if there were conventional means of expressing them you
could make your code more understandable.
--
joe
Christopher Browne
On 07 May 1998 08:05:48 -1000, Joseph Allen Dane <jd...@hawaii.edu>
wrote:
>> "Scheme Patterns" strikes me as a contradiction in terms.
>I agree with this, but I don't think it takes into account the very
>good point that Will Hartung has made: that the expressiveness of
>scheme can make scheme code somewhat impenetrable to outsiders. With
>sufficient effort, of course, a reader unfamiliar with the
>abstractions used could figure it out, but if the code used conventional
>idioms things might be a bit easier. Which isn't to say scheme needs
>to be LISP, only that there are, uhh, "patterns" which pop up all the
>time and if there were conventional means of expressing them you
>could make your code more understandable.
Interestingly, this provides a further parallel between Scheme and K&R
C. (ANSI C is rather more complex/"rich"/capricously-difficult-to-fully
deal with...)
- Both are, or were, fairly small languages;
- Both have been relatively easy to write compilers for;
- (Here's where it starts connecting, I hope...) Both languages are
fairly "sparse" in terms of the things directly implemented in the
language and the "standard" libraries.
In order to have a "rich" environment that allows ready implementation
of "common things," there is a tendancy to implement custom "libraries"
and "macros."
And this leads to sets of "libraries"/"idioms"/"patterns" that wind up
getting reinvented perhaps *too* many times, and that wind up having
idiosyncracies.
The code for the "Bourne Shell" was apparently written using C
preprocessor macros that sought to provide a C syntax that looked as
much as possible like Algol. This turned, unfortunately, into an
unmaintainable mess, as you didn't just have to fight with C and its
syntax, but also with the way the "Algol" macros were implemented.
And there's a tough balancing act here.
- If you start pushing *lots* of stuff into the "standard libraries,"
this is good, insofar as the standard libraries become a rich repository
of functionality.
- This is also *BAD* because the language and standard libraries become
more complex and difficult to understand.
--
Linux is obsolete -- (Andrew Tanenbaum)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Rainer Joswig
Thant Tessman <th...@bogus.acm.org> writes:
> "Scheme Patterns" strikes me as a contradiction in terms.
I don't agree.
> "Design Patterns" are a phenomenon of traditional object-oriented
> programming languages, not languages like Scheme.
See the remarks on Peter Norvig's site (http://www.norvig.com/).
He has a presentation about patterns in dynamic languages (whatever
that is).
Gregg Reynolds
Thant Tessman wrote:
>
> "Scheme Patterns" strikes me as a contradiction in terms.
>
> traditional programming languages just aren't that expressive--they only
> support well the abstractions built directly into the language.
> Consequently, there are many common tasks that require a lot of
> elaboration. Searching for design patterns is simply an attempt to
> formalize the elaboration necessary to support abstractions not directly
> supported by the language.
>
> By contrast, a language like Scheme supports far more than any
> tratitional language the ability to write programs that write programs.
> In a sense, it's a programming language good for building programming
> languages. This makes it easy to introduce new abstractions in a way
> that makes them look and feel like they were designed into the language
> from the start.
>
> So when using a programming language like Scheme, as soon as you
> recognize a "design pattern" you write something to automate the
> expression of that pattern. And then you move on to something else.
>
> -thant
Dear Thant,
I think I understand your thinking, but I suspect that the people
engaged in cataloging "patterns" (a vague and unfortunate term IMHO) do
so without regard to implementation language. In fact I'm sure of it.
The "Gang of Four" book explicitly aims to "capture design experience in
a form that people can use effectively". (p. 2) A classic example is
the MVC pattern for GUI development. However, such pattern catalogs
also tend explicitly to target such patterns as arise in the design of
OO systems. The real goal of the patterns "movement", if we can call it
that, is the creation of a catalog of *design* patterns, which should be
useful regardless of the implementation language. So Scheme users
should be able to profit from such catalogs as much as anybody else.
The language of patterns in software engineering is derived from the
work of an architect, Christopher Alexander, who was trying to discern
recurring patterns in the solutions people have invented over the
centuries to common design problems. "Each pattern describes a problem
which occurs over and over again in our environment, and then describes
the core of the solution to that problem, in such a way that you can use
this solution a million times over, without ever doing it the same way
twice." (quoted in "Design Patterns", p. 2)
So Will was correct to point out that what I was looking for in my
original post was idioms, not patterns. Patterns (in this restricted
sense) must by definition transcend any particular language. What I'm
looking for is guidance in first recognizing the problems (or classes of
problems) for which the genius of Scheme is particularly well-suited,
and second, in using the the language to solve those problems well. Or
maybe it
would be more accurate to say I'm looking for the concrete examples
(experience)
that will help make the transition to "thinking in Scheme".
Ironically, my first encounter with the idea of programming idioms came
with James Coplien's "Advanced C++, Programming Styles and Idioms",
wherein he writes "...C++ developed building blocks that programmers
could use to code their own models of computation. . . Many common
programming tasks became *idiomatic*, using C++ constructs to express
functionality outside the language proper, while giving the illusion of
being part of the language." (pp. 2-3) Almost exactly the same virtues
you correctly attribute to Scheme.
So each language has its virtues. For me the great thing about Scheme
is that its syntax is beginning to feel like the "natural" way to think
about computing; that is, the syntax of the language doesn't get in the
way. When I think about problems in Scheme, I get the feeling that I'm
thinking about computation, and the tool I'm using is malleable enough
to
adapt to the requirements of the problem; whereas when I try to solve
problems in C
(or any other imperative language including Java) my attention is
mercilessly distracted by features of the language, or even worse, by
features of the machine architecture reflected in the language. The
skull beneath the skin, as it were.
So a catalog of Scheme idioms is what I at least am looking for. Very
simple and obvious example: use of recursion to handle some simple
problems. I would consider this a Scheme idiom. After all, one can use
traditional iteratative designs in Scheme, and one can do recursion in
imperative
languages, but it's the native idiom of Scheme. Another example is the
"collector" idiom, as presented in "The Little Schemer". A "natural"
and very powerful idiom in Scheme; I've
never tried it in C, and if I had to I'll wager I'd spend lots of time
figuring out how to match the syntax of the language with the abstract
computational notion of a collector. Then again, maybe I have used it
in C,
without recognizing it as an idiom/pattern.
Lots of interesting info on patterns at
http://hillside.net/patterns/patterns.html. Another interesting site is
at Bell Labs (administered by James Coplien) at
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns. Most of the
patterns there don't even deal with software, which reinforces the point
that patterns are larger than any particular programming language.
Thanks,
-- Gregg
Thant Tessman
Gregg Reynolds wrote:
> I think I understand your thinking, but I suspect that the
> people engaged in cataloging "patterns" (a vague and unfortunate
> term IMHO) do so without regard to implementation language. In
> fact I'm sure of it. [...]
That is indeed the claim. But I call bullshit. 80% of books like
"Design Patterns" and "Advanced C++..." are dedicated to describing
techniques for getting around bad type systems, the lack of memory
management, and other limitations of bad languages. These books are
good books, invaluable if you're stuck programming in C++, but they're a
waste of energy otherwise.
One of my favorite examples is the "COMMAND" pattern. It is nothing
more than a complicated substitute for a closure--something built in a
functional programming language with no more effort than typing
"lambda".
And when you take out the techniques for getting around the limitations
of bad languages, what you're left with is really just specific
applications of the much more general design principle that abstraction
is good. (The MVC `pattern', for example).
All languages have biases. All languages favor some solutions over
others. And it's important to understand the biases of the language you
use. So I'm sympathetic to your search for a description of "Scheme
idioms" and I wish I could recommend something. And I wish I had
something like that when I was learning Scheme. But these biases
shouldn't be celebrated. Instead they should be seen as the limitations
they are.
Sorry. Too much C++ programming has made me a little grumpy. "Design
Patterns" are a pet peeve of mine.
-thant
Antonio
El Fri, 08 May 1998 08:55:36 -0700, Thant Tessman escribió:
>Gregg Reynolds wrote:
>
>> I think I understand your thinking, but I suspect that the
>> people engaged in cataloging "patterns" (a vague and unfortunate
>> term IMHO) do so without regard to implementation language. In
>
>That is indeed the claim. But I call bullshit. 80% of books like
>"Design Patterns" and "Advanced C++..." are dedicated to describing
>techniques for getting around bad type systems, the lack of memory
>management, and other limitations of bad languages. These books are
>good books, invaluable if you're stuck programming in C++, but they're a
>waste of energy otherwise.
IMHO, Design Patterns are independent of the language you are using.
They are even independent of the paradigm you are using.
I first met Lisp a few months ago, and soon changed to Scheme. My
impressions were similar to Gregg's. A new world and a new way of
doing things. Since then I program in a different way in (sigh) C++.
The fact is that I wanted to work a little bit with graphs in Scheme.
It's not that difficult, you may say, but it was not clear to me then.
I didn't realize I could use a hash-table way of storing a graph, so I
started programming a weird thing, trying to keep memory requirements
low. The hash-table solution, where a hash-table entry (a list, of
course) keeps track of a node (the key) and of all its adjacent nodes
in the graph, is more elegant and, of course, faster.
That experience could be rewritten as a design pattern in Scheme.
In fact most experiences can be rewritten in a pattern-like
language. You can verify this by wandering around "The Patterns
Homepage" (at http://hillside.net/patterns/patterns.html).
There you can find a good definition that has nothing to do
with objects (by J. Coplien, who is now working on patterns, at
http://hillside.net/patterns/definition.html).
Then there exists the "Portland Pattern Repository".
(http://c2.com/ppr/formatting.html)
You can place your own patterns there (via e-mail). You can find
patterns for "Code Formatting" , for instance. That has nothing to do
with object-oriented programming, nor with memory management!
Oh. And Wiki. You can modify the web page. Yes you can.
http://c2.com/cgi/wiki
And you can fight with the pattern definitions at:
http://c2.com/cgi/wiki?PatternDefinitionThread
And you have the "OrgPatterns" web site (?) maintained by J. Coplien.
That's a news-server, an e-mail system and a kind of web page. "a way
of communicating asynchronously across the network", they say. The
site is worth a look. It's another experience in the web. Definitely.
You can take a look at the page "On the Interation of Social Issues
and Software Architecture" (wow! that's a pattern?) at
http://www.bell-labs.com/cgi-user/...
...OrgPatterns/OrgPatterns?SocialIssuesAndSoftwareArchitecture
>All languages have biases. All languages favor some solutions over
>others. And it's important to understand the biases of the language you
>use. So I'm sympathetic to your search for a description of "Scheme
>idioms" and I wish I could recommend something. And I wish I had
>something like that when I was learning Scheme. But these biases
>shouldn't be celebrated. Instead they should be seen as the limitations
>they are.
Design patterns alleviate limitations, you say? Mmm. Let me think
patterns will be present in software development in the future as a
new technique of design. Then everything will be much easier. Even in
Scheme!
Regards,
Antonio
Rainer Joswig
>sufficient effort, of course, a reader unfamiliar with the
>abstractions used could figure it out, but if the code used conventional
>idioms things might be a bit easier. Which isn't to say scheme needs
>to be LISP, only that there are, uhh, "patterns" which pop up all the
Hmm.. I always thought Scheme is Lisp. Maybe I'm wrong.
Joseph Allen Dane
"Rainer Joswig" <jos...@lavielle.com> writes:
Of course not, and I am pretty sure you know that. I suppose what I
meant above was "Common LISP", and I probably should have said as
much. But I think few people would be confused when asked to describe
the differences between Scheme and LISP.
Now, if you had said "Scheme is *a* Lisp", I wouldn't have argued at
all.
--
joe
John Miller
It seems like pattern cataloging sounds a bit like developing
an ontology. Unfortunately I don't have SICP with me, but
there is an absolutely amazing and insightful comment on
developing ontologies w.r.t. OO design.
I guess the point that I am trying to make is that talk of
developing patterns makes me a bit wary since such universal
generalizations are very difficult to make. Not that such
a thing is necessarily a waste of time, but one should aware
of possible limitations in such endeavors.
However, the talk about idioms is very interesting. There is
no substitute for knowing the language you are working with
(as a corollary there is no substitute for understanding the
problem either!)
Gregg Reynolds
John Miller wrote:
>
> It seems like pattern cataloging sounds a bit like developing
> an ontology. Unfortunately I don't have SICP with me, but
> there is an absolutely amazing and insightful comment on
> developing ontologies w.r.t. OO design.
>
and the confusion that exists now is that now a variety of inadequate
ontological theories have been embodied in a plethora of correspondingly
inadequate programming languages...much of the complexity of
object-oriented programming languages ... centers on the treatment of
generic operations on interrelated types...we suspect that these
problems cannot be adequately addressed in terms of computer-language
design alone, without also drawing on work in knowledge representation
and automated reasoning." SICP p. 200 fn. 52.
In the case of "design patterns" a retreat to the originator's works is
refreshing. From "A Timeless Way of Building", by Christopher
Alexander: "The people can shape buildings for themselves, and have
done it for centuries, by using languages which I call pattern
languages. A pattern language gives each person who uses it, the power
to create an infinite variety of new and unique buildings, just as his
ordinary language gives him the power to create an infinite variety of
sentences." (p. 167)
"The proper answer to the question, "How is a farmer able to make a new
barn?" lies in the fact that every barn is made of patterns...these
patterns are expressed as rules of thumb, which any farmer can combine
and re-combine to make an infinite variety of unique barns." (p 179)
Almost sounds like he's describing Scheme, doesn't it? I confess I
haven't read the whole book, but it is very interesting, really a
quasi-religious meditation on the arts and practices of architecture.
All this farm talk has tickled an obscure neuron in my brain and
reminded me of Levi-Strauss' "The Savage Mind". Of course I can't find
my copy now, but as I recall he argued that the mind of the "savage",
far from being irrational, was highly refined and rational, just not
scientific in the modern western sense. I believe he used the term
"bricolage" to describe the kind of thought and making to goes on in our
farmer's mind, as well as the classic "savage" mind. Anybody out there
have a copy of Levi-Strauss handy?
Actually, "The Savage Programmer" doesn't sound too bad as the name of a
Scheme website, or an O'Reilly book.
Coming soon: "The Rime of the Ancient Coboler", just as soon as I can
figure out how to make "lambda" rhyme with "albatross". Also: "O
Lambda, My Lambda", in which our poet laments the untimely demise of the
Lambda Calculus, which, having guided the ship of computation through
the language wars, is laid low by one Johnbill Wilkes Boothgates. And
don't miss "Waiting for (A 4 2)".
Jesse Bouwman
>Coming soon: "The Rime of the Ancient Coboler", just as soon as I can
>figure out how to make "lambda" rhyme with "albatross". Also: "O
>Lambda, My Lambda", in which our poet laments the untimely demise of the
No, no.. slide over into the decadently librarified CL and call your
catalog of idioms 'Les Fleurs d'Eval.'
Will Hartung
Rainer Joswig <jos...@lise.lavielle.com> writes:
>Thant Tessman <th...@bogus.acm.org> writes:
>> "Scheme Patterns" strikes me as a contradiction in terms.
>I don't agree.
>> "Design Patterns" are a phenomenon of traditional object-oriented
>> programming languages, not languages like Scheme.
>See the remarks on Peter Norvig's site (http://www.norvig.com/).
>He has a presentation about patterns in dynamic languages (whatever
>that is).
I went over and looked at Peters presentation. I think it's pretty
good. I would liked to have heard the talk that went along with the
slides on the web site. I think that it makes that point that while
patterns are useful in dynamic languages, most of the patterns in the
"gang of four" book are not necessary in a dynamic language. Those
capabilities come for "free". (I have never read the Go4 book, but it
seems clear that this is the work that Peter is referencing in his
presentation.)
In this other pattern book that I have (not that I remember ther NAME
mind you), the author uses the pattern technique to discuss
application domains, like accounting. Here the author presents each
application piece using a generic object model diagram, though he
fleshes them out a bit with some Smalltalk.
Each piece could be considered a pattern of abstraction used to
implement the specific problem. All of the ones I looked at are
hardly "full" implementations, as they all need to be filled in with
detail. This makes sense. A full implementation would just clutter the
pattern.
The fact that these patterns were derived from Smalltalk designs, and
then described in Smalltalk doesn't particularly limit them to
Smalltalk. It limits how the object model is used (e.g. multiple
inheritance), but it's a pretty LCD object model anyways. There's no
reason such a pattern could not be used as a bootstrap for a design
being implemented in Scheme.
The most major complaint to using a pattern from one object model in
another is that if the translation of the pattern into Scheme is done
fairly literally, then the result may not seem "Schemey" (or Lispy)
enough. I don't think it will end up like "Fortran written in Scheme",
but it could have an un-natrual feel to it by not leveraging the
available object model completely. Of course, this is a moot point as
Scheme doesn't have a "standard object model", unlike CL with CLOS.
These application patterns, however, are not "idioms". They're far too
large and unwieldly. I think idioms are very language specific as they
have as much to do with the grammar, syntax and possibily performance
as they do with abstractions.
Moving on, folks interested in patterns may find the book "Patterns in
Software" by Richard Gabriel worth reading. I can get a specific cite
on request, but it's 150ish pages, really well written, and costs
about $15.
There is an interesting discussion that starts with Alexanders
Patterns in architecture works, but follows through to how well these
patterns did (or did not) work in Real Life(tm). Richard goes on to
discuss how these issues relate to their use in software as well. His
is a different approach than what Peter did, and not specific to
dynamic languages.
The book continues on with a bit on Turkish rugs, gets a bit
autobiographical, and has some interesting Lisp history in it. More of
a philisophical software book that a technical book. Very readable.
Bruce Tobin
Rainer Joswig wrote:
> Thant Tessman <th...@bogus.acm.org> writes:
>
> > "Scheme Patterns" strikes me as a contradiction in terms.
>
> I don't agree.
>
> > "Design Patterns" are a phenomenon of traditional object-oriented
> > programming languages, not languages like Scheme.
>
> See the remarks on Peter Norvig's site (http://www.norvig.com/).
> He has a presentation about patterns in dynamic languages (whatever
> that is).
Well, I'm glad someone mentioned that URL; saves me the trouble. But
Norvig's and Tessman's positions are not so far apart as your post seems
to imply. Norvig points out that many of the patterns in "Design
Patterns" only exist because of language limitations and are implemented
"invisibly" in dynamic languages such as CL and Dylan. He also notes
that many of the rest can be specified formally via macros in such
languages, again obviating the need for a design pattern specification.
On the other hand, he also notes that not every pattern identified by
Gamma et. al. can be dealt with in this fashion, and he suggests new,
higher-level patterns specifically tailored to dynamic languages.
If a language were perfectly expressive, then any abstraction that could
be conceived could also be expressed formally in the language. Such a
language would indeed have no use for pattern-level design
specifications. I don't think such a language exists, though.