I think the argument has merit.  the reason is simple: if you want
  something to be very popular, you have to _design_ it so you know how the
  distribution of capabilities of your adherents is going to look.  if you
  aim for a normal distribution and a certain number of people, you may
  have to avoid abstractions because there aren't that many people who are
  able to deal with them.  patterns, however, fit much better with how
  people who are weak at abstractions work: cut and paste, modify example
  code, and "reuse" through random proliferation.

  in many ways, modern language design is an attempt to solve the problem
  of how to avoid serious damage by the average programmers.  we can't rely
  on good programmers, anymore, so the people who become programmers for
  the money they need to pay for normal family life expenditures like wife,
  kids, house, cars, etc, quite unlike the dedicated programmers of times
  past, have very different _real_ interests and are unlikely to get really
  involved in their work, just like most other average people are much more
  interested in beer and sports than their work.

  another argument is that abstraction is something you get used to through
  very hard training, and if you don't get used to it, you won't be able to
  pick it up at random, either.  I don't know exactly how some people get
  better at abstractions than others, but I have no problem understanding
  that some forms of abstractions may require immersion into a field for a
  very long time, but maybe it's more than immersion, and maybe it isn't.

  if it is just a matter of immersion and exposing people to more abstract
  ways of thinking so they get used to it, removing abstractions from out
  of reach of average people is doing them a fundamental disservice and
  patterns is a sure-fire way of never improving the lot of mankind.  if
  there is some genetic quality to abstractions (I don't believe there is)
  that makes only a small portion of the population able to deal with them
  successfully, then patterns is a very good solution to having overreached
  the capacity of the human brain.

  that is, given the current tendency to view people are unchangeable and
  more or less genetically predetermined, "patterns" emerges as a solution
  to the problem of the failure of abstraction to get hold in the masses of
  people who want to write software for money, but the core argument is at
  fault: people are able to learn abstraction if they have to and get used
  to it: expose them to it, and they get it in time.  if they can run away,
  however, most will.  letting them run away is no good solution to the
  fundamental problem of programming in society: we need responsible people
  who don't make stupid mistakes in critical software that is already far
  too complex for the human mind to understand in its entirety.

  I don't think the answer to the core problems can be anything but giving
  people more abstract tools and better tools for abstraction.  I don't
  think patterns is anything but a serious deterrent to learn abstraction
  -- mostly because the variation between applications is supposed to be
  more important than the similarities, which only means that people are
  muddling the issues -- and gain popularity out of a form of despair: we
  can't educate people fast enough, and young people just make too much
  money before they have graduated, or at least hope they can, so we have
  to design something that such people can deal with at their abstraction
  levels.

  where's Lisp in all of this?  I'll repeat something I said at LUGM'99:
  "Common Lisp is a language you graduate into."  I think people will find
  Lisp suitable after they crave something better than they have been bored
  of repeating.  consider the programmer who realizes "why keep repeating
  this nine-line code fragment all over the place when the function is much
  easily expressed as a MISMATCH function call?" -- that's the kind we want
  to graduate into Common Lisp.  but this won't happen if patterns is the
  best solution they can think of, or they don't realize that patterns are
  intended to keep people who can't handle power tools from hurting people.

  put another way: patterns emerge from people solving problems over and
  over in better and better ways.  abstractions emerge from patterns when
  the confusion of elements in the patterns are isolated and crystallized.
  familiarity with patterns is necessary to forming abstractions, but the
  focus on patterns means that people are allowed to _stay_ confused.

That's because the example has been carefully chosen so that on
typical lisps it doesn't matter which one you do since the consing
because of MAPCAR (and the function call overhead on each list
element) is completely dominant in most implementations.  So the
unwary will be trapped into thinking that you just don't need to care.

In real life things are more complex.  You need to know if there is a
performance issue, for instance, and both avoid the C-programmer's case
of optimizing / abstracting some thing that maps over lists which
never have more than 3 elements, and only gets called at
macro-expansion time anyway, and the lisp-programmer's case of doing
your numerically-intensive array bashing code with arrays represented
as lists, and dying horribly that way.

This notwithstanding, patterns do help abstraction. The abstraction is
not expressible in the code itself, but it can be identified and
documented. Before the advent of explicitly codified patterns these
abstractions would most of the time have gone unnoticed! In this way,
patterns pull the level of discourse toward more abstraction. This
conclusion may not apply to the Lisp programming community, but it fits
the C++ and Java communities very well (I can't tell for Smalltalk).

Michael

  huh?  I'm saying that people who aren't very good at abstraction write
  _code_ using cut-and-paste techniques and that patterns fit this mode.
  this is obviously different from cutting and pasting "patterns", which I
  find to be a nonsensical statement -- it's like saying that you can't
  copy somebody's idea because Xerox machines don't work that way.

| This notwithstanding, patterns do help abstraction. The abstraction is
| not expressible in the code itself, but it can be identified and
| documented. Before the advent of explicitly codified patterns these
| abstractions would most of the time have gone unnoticed! In this way,
| patterns pull the level of discourse toward more abstraction. This
| conclusion may not apply to the Lisp programming community, but it fits
| the C++ and Java communities very well (I can't tell for Smalltalk).

  I think you might want to read my article again, since this doesn't seem
  as if you're doing anything but try to re-phrase what I said in a light
  somewhat more favorable to patterns.

  incidentally, I'm strongly ambivalent on patterns.  I hate them if they
  are used to destroy our ability to solve problems once and for all
  without the need for the repetitiveness of reimplementing them verbosely
  all the time, and that is a recurring argument in their _favor_ by people
  who think that most complex problems don't actually _have_ solutions.  I
  love them if they are used to keep people who can't write good code from
  writing really bad code.  ideally, we should get rid of the people who
  can't write good code, and thus raise the average and our concept of what
  "can't write good code" means, then keep doing this iteratively until
  programming became a serious profession with social responsibility.

  an amusing epitaph!  I wish I had written this myself, as I quite I agree
  that Christopher Alexander's work is amazingly interesting for the field
  in which he thought it up, but I, too, fail to see how it applies to the
  way software is built.  this doesn't mean we don't need to figure out how
  we come by our abstractions, and maybe it progresses through stages that,
  if not viewed as stages, could be very close to architectural patterns.

  this is getting vague, but my impression here is that somebody has seen
  something and have grappled for a name and not found one.  then there's
  this quality without a name, but the only thing that really matches up
  with the software people's grappling for a name is the lack of a name.
  two things both lacking a name aren't commonly thought to be the same,
  but that's how I think the misapplication of patterns to software was
  born.  nonetheless, it's very interesting to have seen it expanded upon
  and we're the richer for having had some work in this area, but let's
  figure out why we didn't really win this time, either, and move on.

I took you to rely on the premise that patterns hinder abstraction. But
our misunderstanding may be caused by two very different points of view
(see below).

In favor of patterns I'd like to add that their introduction into
software has spawned a whole lot of interesting discussions among highly
skilled software developers. In my opinion this is very valuable.

Michael

<digression>
There is a story told about Ludwig Wittgenstein. He had dedicate some number of
years to writing a book called the Tractatus, describing everything that could be
said. He then gave this book to a friend, an Italian  philosopher whose name
escapes me, to read. On having read the manuscript, Wittgenstein challenged his
friend to tell him something that wasn't in the book. His friend shrugged his
shoulders, and in a state of anguish Wittgenstein through the book in the bin.
</digression>

Finally, there are lots more things in the world that would be `nicer' that this...

Best Regards,

Norvig provides an example.  He says subroutine call used to be a
pattern (in assembler, say).  Yet now subroutine call clearly is
built into languages.  Now, it seems to me that Michael Schuerig
has to disagree with Norvig here and say that it never was a pattern
or else deny the obvious fact that subroutine call is built into
languages.

I suspect that the way out will be to say the *pattern* has not
been build into languages.  It's just that now there's something
in languages that makes the pattern ridiculously easy.

Orwellian-ly yours,

Best Regards,

You say all you meant was "That experts do something is neither a
necessary nor a sufficient condition for it to be a pattern".  But
that means you can't go from "X is a pattern" to "experts do X"
(because the latter is not a necessary condition of the former).

But that immediately raises the question "if experts don't do X,
what do they do instead?"  And example of an X of the sort I had
in mind would be using the visitor pattern in certain specifiable
circumstances which happened to obtain in the case my example
programmer was considering.

Of course, there could be patterns that aren't used by experts, but
only (for instance) by novice programmers (for some reason).  I'm not
trying to suggest that use-by-experts is somehow built into the
definition of "pattern".  I nonetheless continue to feel that
programmers using certain somewhat awkward languages, such as
Java, will find patterns helpful in (a) finding some thought-to-be-
good but not all that obvious ways to do things, and (b) reassuring
them that a way they've worked out is not as bad as it looked --
and that this is less so in certain other languages.

There's a general problem here.  In this discussion of patterns, some
people (in fact, most of them) seem to be using "pattern" in pretty
much it's usual sense.  So we might notice a certain regularity in
how certain things were done -- ie, a pattern -- and call it "a
pattern".  And some such patterns can certainly be "packaged up"
and embodied in a programming language (or added to one via macros
etc).  Mapcar is an example, and there are many, many others.

(Of course, when we write such things up as patterns, we add something
about when to use them and so on.  And then perhaps sometimes "the
pattern" will be meant to include this information about conditions,
etc, and sometimes not; hence, no doubt, much confusion.)

But some people -- you, for instance -- *seem* to be using "pattern"
in some other, presumably more technical, sense.  So some things
that are patterns in the ordinary sense of the word are not
technically patterns at all, but something else, such as idioms.

Moreover, in this view even the GOF book has this wrong and calls
some things patterns when they're not, even though "pattern" ramains
very general.  I just don't see the point of excluding these things
from counting as patterns.  Or, rather, I don't see any good point
to doing it.

<quote>
... the truth of the thoughts that are here communicated seems to me
unassailable and definitive. I therefore believe myself to have found,
on all essential points, the final solution of the problems. And if I am
not mistaken in this belief, then the second thing in which the of this
work consists is that it shows how little is achieved when these problem
are solved.
</quote>

What you're saying in your previous paragraphs and postings is much
closer to the views Wittgenstein espouses in his Philosophical
Investigations.

Michael

Michael

Michael
slightly touchy

  this whole argument is getting rather bizarre in my view.  it seems that
  you attribute to these "patterns" the entire culture of good programming
  practice, and refuse to acknowledge that good programming practice can
  even exist without patterns.  it's like the joke about Freudians: if you
  deny having an Oedipus complex, you're even worse off, because then you
  suffer from _suppressing_ your Oedipus complex.  however, nobody here
  appears to be denying the value of patterns, just the exclusionary point
  that everything else that has value must also be patterns, and that if it
  isn't a pattern, then it lacks goodness in some fundamental sense.  in
  this particular case, consider a textbook and a community of programmers
  who tell their students and new members how to use a langauge feature.
  some would say "ah!  pattern!  I knew it!" while others will argue that
  _teaching_ and _apprenticeship_ are hardly worth patternizing since they
  are already well-established processes and concepts.

  I think it's worth our while to identify certain commonalities in what
  good programmers do when they write good software, but there is a very
  real danger in making everything explicit and spending time talking about
  it: we lose track of its proportions and relevance, and the more we talk
  about one thing to the exclusion of other things, the more we try to tie
  that thing into everything else through the most dubious of connections
  that would be seen as obviously wrong to anyone who had not focused so
  heavily on that particular thing.  this is why it's vital to a healthy
  mind constantly to seek and examine information that runs counter to its
  established ideas and concepts.  only that way can a person maintain the
  crucial psychological belief that what one does believe is superior to
  what one does not or no longer believe.  the alternative is fanaticism.

Obviously good programming practices must have existed before patterns
were written down or else there would have been nothing to write down.
There's even a "law", attributed to Frank Buschmann, that says something
can only be a pattern if there are at least three independent cases of
its successful use. Patterns just capture good practices in a specific
form and that's almost all there is to it.

Michael

     I've been following this discussion for a while but must not
     understand the full gist of the anti-"patterns" argument.
     Surely, many OOP patterns "disappear" in Lisp because the
     language directly supports the desired functionality.  Heck,
     many of the GoF patterns are non-issues in Smalltalk, an OO
     language that directly supports the desired functionality.

     But it seems to me when programming in any language one
     encounters metalinguistic constructs that fall outside the
     language and thus become patterns of design or implementation.
     Lisp certainly supports a much higher degree of abstraction
     than C++, but...

     Consider the situation in which a program processes mutually
     inductive data definitions, say,

                   <s-list> ::= ()
                              | (<symbol-expression> . <s-list>)

        <symbol-expression> ::= <symbol>
                              | <s-list>

     I've seen many functional programs, written by many different
     programmers, create two functions in this case, one for each
     definition.  This is opposed to, say, writing one function
     from scratch for handling s-lists that incorporates the symbol-
     expression handler within.  The fact that I see this solution
     frequently in many different situations seems to indicate that
     mutual recursion is a common pattern in functional programming.
     There are reasons that make this solution preferable to other
     possible solutions, which is part of documenting something as
     a pattern.

     Of course, I can use program derivation to fold the two
     functions into one, but there are trade-offs in readability
     and modifiability made.  Again, this seems to be a pattern that
     reflects balancing the "forces" in a particular application.

     Can we simply automate this idea in a Lisp function, making the
     pattern go away?  I don't think so, because the solution is a
     design-level construct, not a function-implementation construct.
     It refers outside the program to the problem definition.
     Certainly I can create code to support application of the pattern,
     but then again that is what OO programmers do to support the
     application of, say, MVC.

     I'm very interested in hearing the perspective of "expert" Lisp
     programmers in this discussion, because I see things like this:

: A curse on the programmer who first picked up a Christopher Alexander
: book!  Great for buildings, horrible for software.

     ... and wonder if I'm missing something.  I don't see how
     Alexander's idea can be great for buildings and yet horrible
     for software.  We certainly don't understand software to the
     level of creating formal theorems and science for writing it
     yet, and documenting the patterns that occur in real software
     seems like a pretty good way for us to try to understand better.

In addition, most of the work on software patterns has bastardized most of
Alexander's work - look at the stark, dead functionality of GOF pattern
forms with respect to the supple and - dare I say it - "living" form of
Alexander's patterns.  All in all, the software community has a LOT to learn
from Alexander, just as it has a lot to learn from all examples of good
design.  But in reality, the best thing that most software engineers can
learn from him is his concern for people and their lives.  Look at his
OOPSLA address and see how few of his core issues the GOF and the other
pattern mavens expound (or see how many truly tortured analogies they make
to turn his work into somethng that they can attempt to comprehend from a
mechanistic viewpoint).

If you really think the aforementioned statement you made is correct, I
suggest you cut latticework in your code listings (or your disk drives)
because subroutines need divided light just like rooms.

<digression> This is where I would, if I had (or even owned) a copy of the Tractatus
to hand, I would quote the bit at the end about pulling the ladder up after oneself
;) </digression>

However, I must be careful not to sound like the `patterns mystic' who claims that
to reach true pattern enlightenment requires a restricted diet, 14-hours-a-day
mediation on pattern-hood and living in a draughty galvanized-shed some where near
Cader Idris. This is not what I am trying to say.

This may also be to do with things like the axiom set, paradigms, or world view
(what ever you want to call them) on which the communication is based. As an
`communicator' I need to know where you are before I can tailor the delivery of the
description of the `pattern.' For some reason this makes me think of Planck who
taugh himself to swim though a reading a `teach-yourself' manual on swimming. Which
may invalidate some of what I am saying. But whatever.

Alternatively, this could be because I am very bad at communicating and have never
met anybody who was (much) better at this than me. It's just that I have spent some
years looking for descriptions of the methods or patterns of problem solving.

However, please do not take my philosophical ramblings as anything other than that
of an interested member of the great-unwashed. I do not want you to think I have
delusions of philosophical competence, (or adequacy for that matter) ;)

Best Regards,

That's one reason why patterns in how things are done (and there
I am of course using "pattern" in its ordinary sense) are so often
embodied in macros, higher-order functions, classes, or just plain
procedures in Lisp.  (And hence the idea, common in Lisp circles,
of constructing a language within Lisp that's suited to the problems
at hand.)

Then even patterns that are not so embodied become shorter and
easier to recognize.

In practice, the now popular patterns approach is often
counter-abstraction, because it encourages people to write things out
in-line rather than building up the level at which they work by
defining appropriate macros, procedures, and so on.  The result is a
lot of low-level, verbose code.

My suspicion is that one reason why "patterns" are such a big deal
now is that C++ and Java programmers really need them.  For instance,
many things that are straightforward to do in ordinary languages
become significantly more difficult in Java because they have to
fit into a restrictive and rigid form of OOP.

And given that it's reasonably clear, and that it's reasonably clear
what you mean by "pattern" (see below), what's the point of
disagreeing?  What we have is a "merely verbal" dispute around
the word "pattern".

Hence also my remark in another message:

  (Of course, when we write such things [as mapcar] up as patterns, we
  add something about when to use them and so on.  And then perhaps
  sometimes "the pattern" will be meant to include this information
  about conditions, etc, and sometimes not; hence, no doubt, much
  confusion.)

But that's how (natural) language works.

But you did take pretty much the "way out" that I suggested.  That I
could anticipate that is evidence that you had succeeded in making
your meaning clear.

<quote>
6.54
My propositions are elucidatory in this way: he who understands me
finally recognizes them as senseless, when he has climbed out through
them, on them, over them. (He must so to speak throw away the ladder,
after he has climbed up on it.)

7
What we cannot speak about we must pass over in silence.
</quote>

Best regards,
Michael