Making an engineering case for Lisp
David E. Young
research projects, on injecting Common Lisp into our engineering
environment. In January I will have an opportunity to make an
"engineering case" for Lisp as a vehicle to develop real product, and
would like to solicit you folks for annecdotal examples of *real* Lisp
projects and experiences.
I am especially interested in the following:
1. From a software engineering perspective, how does Lisp scale to large
projects? I don't mean performance here; rather, I'm interested in
learning how well a team of developers can build large systems that
exhibit high quality and reliability. I'd wager one of the first
concerns I hear will be from the strongly-typed-language proponents, who
will bemoan Lisp's lack of compile-time type checking. This concern is
legitimate, and I'd like to hear of your experiences in this area.
2. Common Lisp and "mainstream" applications. Most of my research has
centered around the development of knowledge-based systems; however, I'd
like Lisp to be considered a platform for developing complex
applications that don't necessarily have anything to do with AI. I'm
very interested in hearing of your experiences here. I don't need
details (proprietary information and all that), but general information
on existing and (especially) new projects will be valuable.
3. Anyone who's successfully introduced Lisp into their company. Your
guidance here would be appreciated.
I realize your responses require time and effort, but new, visible
project work in Lisp (especially at a company that doesn't officially
use it) can't be anything but good for the language. Thanks very much.
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(de.y...@computer.org) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
Andrew Cooke
"David E. Young" <de.y...@computer.org> wrote:
> I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents,
who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
> 3. Anyone who's successfully introduced Lisp into their company. Your
> guidance here would be appreciated.
I have little experience of Lisp (see my posts here :-), but on the last
point, I was involved in trying to move from C to C++ at one company and
it was depressing. A group of us tried developing a useful project in
our own time using the new language to demonstrate the benefits, but it
was very slow and, by the time I left, had succeeded mainly in
alienating more traditional members of the company who considered us a
clique. If "middle management" aren't happy with changes then it's no
fun....
As for the static types - (I guess I'm about to state the obvious here)
the only argument I can see is that it is much easier to write small
test scripts in Lisp than in Java (the language I learn a living in).
The flexibility of Lisp, esp first class functions and dynamic typing,
means that you can test earlier, and test smaller components. I use
test scripts in Lisp the same way I use the compiler in Java - to track
and fix the ripple-though effect of changes in code. I guess you can
also use the before and after methods in Clos as some kind of invariance
checking (like Eiffel), but I haven't done so.
Good luck,
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
Coby Beck
application of LISP. I don't have any first hand info on the details, but I
know that LISP was used extensivily in the core of the project.
It also used blackboard technology from http://www.bbtech.com/ which is
also implemented with LISP.
The company i work for also impements a large part of its product with LISP.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Coby Beck
Software Developer
__________________________
Mercury Scheduling Systems
400 - 601 West Cordova
Vancouver, BC
ph - (604) 683-8668 ext 370
fax- (604) 688-2375
http://www.mercury.bc.ca/
Email- cb...@mercury.bc.ca
David E. Young <de.y...@computer.org> wrote in message
news:382C2EED...@computer.org...
> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.
>
> I am especially interested in the following:
>
> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
>
> 2. Common Lisp and "mainstream" applications. Most of my research has
> centered around the development of knowledge-based systems; however, I'd
> like Lisp to be considered a platform for developing complex
> applications that don't necessarily have anything to do with AI. I'm
> very interested in hearing of your experiences here. I don't need
> details (proprietary information and all that), but general information
> on existing and (especially) new projects will be valuable.
>
> 3. Anyone who's successfully introduced Lisp into their company. Your
> guidance here would be appreciated.
>
Liam Healy
> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.
>
> I am especially interested in the following:
>
> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
I'll address the specific point you raise; I think for general issues
of scaling and applicability, look at
e.g. http://www.elwoodcorp.com/alu/table/applications.htm or
contact a CL vendor.
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
Since types are not known until runtime, it would be hard to have
compile-time type checking. However, if you insert a check-type call
wherever there might be a problem, you will have as early-as-possible
indication of a problem. Also assert. I find these very useful -
preemptive debugging. It would be nice if a compiler would
automatically insert check-type for each type declaration present, say
if a certain code safety level is specified. That way, you could
declare everything and leave the declarations in, just crank up the
safety level during debugging. This doesn't exist in any CL I know
of.
You might point out the advantages of late binding over strong
typing, too.
--
Liam Healy
Liam....@nrl.navy.mil
Christopher J. Vogt
>
> [ ... ]
>
> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
I'd say that Lisp scales better than most other languages, and this is one
of its benefits. However, my experience suggests that you need at least
one Lisp expert as part of the team to keep the team on the right track.
Large projects built by inexperienced Lisp developers is a nightmare.
In terms of reliability, this is one of the big issues I push as
to an advantage of lisp. Lisp applications don't spontaneously exit like
applications built in other languages seem to do all too often. You also
can load patches into a running system, no need to bring down the system
for maintenance.
As to type checking, all the type checking doesn't seem to prevent memory
leaks in C programs, nor does it seem to prevent bad pointers from causing
the application to spontaneously exit. People may bemoan Lisps lack of
compile time type checking, but they are attaching *way* too much importance
to this issue, and I believe this to be a non sequiter. Type checking doesn't
help me develop C programs any faster, or better than I do in Lisp without
it.
David Hanley
"David E. Young" wrote:
> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.
>
> I am especially interested in the following:
>
> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
Well, you don't have compile time checking in most lisps, but. I'll bet
that most of the "type errors" in C won't be a problem in lisp. With
underclared parameters as long as the function works on the type, it's
ok. You can check the types in function headers to turn up type
errors early in testing. Maybe not as "good" as static checking, but
it can get you quite a lot, while maintaining the flexibility we all know
and love.
dave
Tim Bradshaw
> It would be nice if a compiler would
> automatically insert check-type for each type declaration present, say
> if a certain code safety level is specified. That way, you could
> declare everything and leave the declarations in, just crank up the
> safety level during debugging. This doesn't exist in any CL I know
> of.
That's basically what CMUCL does:
(defun foo (x)
(declare (type real x))
x)
(foo 1) -> 1
(foo t) -> <error>
--tim
David Hanley
Liam Healy wrote: It would be nice if a compiler would
> automatically insert check-type for each type declaration present, say
> if a certain code safety level is specified. That way, you could
> declare everything and leave the declarations in, just crank up the
> safety level during debugging. This doesn't exist in any CL I know
> of.
CMUCL does this for compiled code:
(defun mult( x y )
(declare (type fixnum x y))
(* x y))
(compile 'mult)
(mult 2 2.3)
Type-error in kernel...
2.3 is not of type FIXNUM
This even works for stuff like (integer 1 10)
When you crank on optimizations, its turns the assertions
to assumptions, resulting in very fast code.
dave
Paolo Amoroso
<de.y...@computer.org> wrote:
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.
You may be interested in checking this paper by Erann Gat:
"Lisp as an Alternative to Java"
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Andrew Cooke
> > concerns I hear will be from the strongly-typed-language proponents,
who
> > will bemoan Lisp's lack of compile-time type checking. This concern
is
> > legitimate, and I'd like to hear of your experiences in this area.
> As to type checking, all the type checking doesn't seem to prevent
memory
> leaks in C programs, nor does it seem to prevent bad pointers from
causing
> the application to spontaneously exit. People may bemoan Lisps lack
of
> compile time type checking, but they are attaching *way* too much
importance
> to this issue, and I believe this to be a non sequiter. Type checking
doesn't
> help me develop C programs any faster, or better than I do in Lisp
without
> it.
A (pedantic) aside:
First, Lisp is strongly typed, but is has strong *dynamic* typing, not
strong *static* typing. So if the "objectors" want a strongly typed
language (one in which the type of an object is always known), then Lisp
fits the bill. However, I assumed the original question was talking
about strong static types, which give compile time type checking (if so,
what language? Eiffel? Java? You can point out Java isn't static as
you can have class cast exceptions....)
C is weakly typed, and C++ is a mess, so it's not surprising that C
programs have memory errors. If the "objectors" are arguing for C then
the argument in favour of Lisp is clear - it is strongly typed and C is
not!
Hope that is clear. I also hope it's right. I didn't have a computer
science education so I've just picked up these things on the way - I
suspect most people here can correct me if I'm wrong.
Andrew Cooke
Andrew Cooke <and...@andrewcooke.free-online.co.uk> wrote:
> In article <382C711F...@computer.org>,
> vo...@computer.org wrote:
> > "David E. Young" wrote:
> [...]
> > > exhibit high quality and reliability. I'd wager one of the first
> > > concerns I hear will be from the strongly-typed-language
proponents,
> who
> > > will bemoan Lisp's lack of compile-time type checking. This
concern
> is
> > > legitimate, and I'd like to hear of your experiences in this area.
> [...]
> programs have memory errors. If the "objectors" are arguing for C
then
> the argument in favour of Lisp is clear - it is strongly typed and C
is
> not!
PS I decided not to add this as it's aimed at a pretty uneducated
reader, then changed my mind after posting because it really may be
useful if you are dealing with people who have only ever used C. It's a
survey of programing languages that probably contains some errors, but
might be useful if you are trying to sell a new language to people who
don't realise that there is a lot more than just C. Even if the article
isn't any good, the links at the end to similar articles by others might
help.
http://www.andrewcooke.free-online.co.uk/andrew/writing/lang.html
Fred Gilham
There's a certain irony in arguing that Lisp is faulty because it
doesn't have static typing like C. In fact, the thing to realize is
that in Lisp, variables do not have types; instead, EVERY LISP OBJECT
has a type. This is what Lisp's tag bits are all about. Variables
are just names for values (see `Lambda, the Ultimate Declarative' by
Guy Steele).
In other words, Lisp sacrifices a certain level of performance (a
sacrifice that can often be retrieved by careful use of declarations)
in exchange for making sure that the system knows exactly what kind of
thing every object is. This removes the need for the programmer to
worry about telling the system something it already knows. But, since
people are used to thinking in terms of C, they think this is a flaw,
when it is actually a programming aid, like garbage collection.
Languages like C are flawed because they don't know what the objects
they are representing actually are. They put the onus for dealing
with this on the programmer and that leads to programming errors.
I speak as someone who has been involved in several good-sized
projects that used C.
--
Fred Gilham gil...@csl.sri.com
The real point is how much easier it was to conceive of and design the
Lisp version. I hadn't even realized the problem was hard until
people started to recode it in C.... --Lawrence Hunter, Ph.D.
Robert Monfera
You wrote:
> I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents,
> who will bemoan Lisp's lack of compile-time type checking.
If you use generic functions, it's customary to have a fall-back method,
which only becomes the effective method when the GF is invoked with
arguments of incorrect classes. There it's your choice if you raise an
error, or write something in an error log etc.
Alright, classes are not the same as types, but in large applications
you may need class checking for instances a lot more often than type
checking. Also, it's possible to change the class of an instance if it
meets some criteria (e.g., if both dimensions of a rectangle are the
same length, you may upgrade it to make it a square instance with
change-class), providing you with an alternative to deftype.
If your application uses integers or rationals, this is an area where
lisp bignums and rationals are certainly safer (rationals: more
accurate) than what you can do in C.
Also, in C or C++ you would often pass around pointers. I'm not sure if
there is a lot of type checking on the objects referred by those
pointers.
A question: do you feel that the decision-makers have experienced or
recognized some of CL's benefits already?
Robert
Rainer Joswig
> 2. Common Lisp and "mainstream" applications. Most of my research has
> centered around the development of knowledge-based systems; however, I'd
> like Lisp to be considered a platform for developing complex
> applications that don't necessarily have anything to do with AI. I'm
> very interested in hearing of your experiences here. I don't need
> details (proprietary information and all that), but general information
> on existing and (especially) new projects will be valuable.
For some marketing talk see:
Common Lisp Language Overview
http://www.harlequin.com/products/st/lisp/language.shtml
and especially:
Common Lisp - Myths and Legends
http://www.harlequin.com/support/lisp-info/lisp-white.html
Rainer Joswig, ISION Internet AG, Harburger Schlossstraße 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: rainer...@ision.de , WWW: http://www.ision.de/
Samir Barjoud
>
> If you use generic functions, it's customary to have a fall-back method,
> which only becomes the effective method when the GF is invoked with
> arguments of incorrect classes. There it's your choice if you raise an
> error, or write something in an error log etc.
>
There's no need for a fall-back method if you just want an error to be
signalled. That is the default behavior.
From the Hyperspec entry for NO-APPLICABLE-METHOD:
:The generic function no-applicable-method is called when a generic
:function is invoked and no :method on that generic function is
:applicable. The default method signals an error.
> Alright, classes are not the same as types, but in large applications
> you may need class checking for instances a lot more often than type
> checking.
> [...]
Why?
--
Samir Barjoud
sa...@mindspring.com
Paolo Amoroso
wrote:
> Check this for an example of a high profile, high tech and real-time
> application of LISP. I don't have any first hand info on the details, but I
> know that LISP was used extensivily in the core of the project.
>
> http://radarsat.space.gc.ca/
>
> It also used blackboard technology from http://www.bbtech.com/ which is
> also implemented with LISP.
I don't know if it's related, but the following paper looks interesting:
"A Tutorial on LISP Object-Oriented Programming for Blackboard
Computation (Solving the Radar Tracking Problem)"
P.R. Kersten, A.C. Kak
International Journal of Intelligent Systems
Vol. 8, pages 617-669 - 1993
Robert Monfera
> There's no need for a fall-back method if you just want an error to
> be signalled. That is the default behavior.
You are right - I was referring to a more customized error message
delivery, which is more understandable (e.g., more specific) to users,
and you may want to take action other than error signaling.
Also, based on Duane's recent posting on how elegantly dispatch is
implemented, and the MOP, then implementations actually create a default
method for every GF which just signal an error.
> > Alright, classes are not the same as types, but in large
> > applications you may need class checking for instances a lot more
> > often than type checking.
> Why?
I feel that in general, the more complex the application (and thus the
level of abstraction), the higher the share of structured information
packages (objects like structure or class instances) in the information
flow among functions.
If you are building an application that is capable of pricing many types
of financial instruments, and pricing itself has several components
(risks, overhead costs, opportunity interest, exceptional policies...),
then you are likely to build class hierarchies to represent the nature
of your products, and specialize methods for them. You may want to
decompose structured products to atomic financial transactions, price
them and combine the results. You need only a little type checking -
for example, whether incoming data are correct - but even that is
run-type checking. (If you don't feel convinced by this example, maybe
you could give some details and examples where you want many functions
of your application to fail when invoked with an object that is not a
member of a type.)
It is not by accident that programs use DEFCLASS more often for
abstraction and enabling dispatch than DEFTYPE. If you find that your
program is full of TYPECASE's, maybe you should use method dispatch.
Erik had a recent posting on making a defined and useful distinction
between classes and types. When people say they want strong typing, I
think they mean they want strong classing - making sure that parameter
carries a string, or an integer, or a call option instrument - more
often than they actually mean strong typing - the parameter be an
integer between 50 and 150, for example).
Robert
Rainer Joswig
> Erik had a recent posting on making a defined and useful distinction
> between classes and types. When people say they want strong typing, I
> think they mean they want strong classing - making sure that parameter
> carries a string, or an integer, or a call option instrument - more
> often than they actually mean strong typing - the parameter be an
> integer between 50 and 150, for example).
see the use of "Presentation Types" in CLIM
Paolo Amoroso
<de.y...@computer.org> wrote:
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.
Some real Lisp applications are described in the proceedings of the latest
Lisp events: LUGM '99 (Lisp User Group Meeting '99; October 1999), ELUGM
(European Lisp User Group Meeting '99; June 1999) and the "Lisp in the
Mainstream - 40th Anniversary of Lisp" conference (November 1998). To get
the proceedings contact Franz's sales department.
Another interesting resource is the following paper by Richard Fateman:
"Software Fault Prevention by Language Choice: Why C is Not my Favorite
Language"
http://www.cs.berkeley.edu/~fateman/papers/software.pdf
David Thornley
>leaks in C programs,
In isolation, I find this a very strange statement, since I don't see why
type checking would prevent memory leaks. I suppose the relevance is that
C/C++ programs tend to suffer from memory problems that simply do not
exist in Common Lisp.
I suppose, then, that an engineering case for CL would include looking
at the errors that occur in the probable other choices.
I've seen references to 30% of the debugging effort in C/C++ going into
memory issues, and in my experience they aren't all solved anyway.
Time spent in CL with similar issues: 0%. (Well, you can do your
own memory management in CL, and I suppose you could run into problems
by doing so, but it's a lot easier to do and a lot easier to get right.)
CL's integer arithmetic has the amazing property of being correct. In
most systems, generating an integer that is out of bounds simply gives
an incorrect result, while in some it crashes the machine. In CL, it
slows down the processing a bit. How confident are you of the size of
your intermediate results?
Anybody else care to name something that is (or really should be) an issue
in C/C++ programming that is a non-issue in CL?
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Sam Steingold
<http://www.podval.org/~sds/tool.html>
useful.
--
Sam Steingold (http://www.podval.org/~sds/)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
(let ((a "(let ((a %c%s%c)) (format a 34 a 34))")) (format a 34 a 34))
Mitchell Morris
>2. Common Lisp and "mainstream" applications. Most of my research has
>centered around the development of knowledge-based systems; however, I'd
>like Lisp to be considered a platform for developing complex
>applications that don't necessarily have anything to do with AI. I'm
>very interested in hearing of your experiences here. I don't need
>details (proprietary information and all that), but general information
>on existing and (especially) new projects will be valuable.
>
>"Programming should be fun,
> programs should be beautiful"
> -- P. Graham
I'm not sure how relevant this is in terms of reliability or robustness,
but it certainly is mainstream and performance-critical:
Crash Bandicoot for the Sony PlayStation
Article starts at:
<URL:http://www.gamasutra.com/features/19991112/GavinWhite_01.htm>
with the portions Lisp-related on page three:
<URL:http://www.gamasutra.com/features/19991112/GavinWhite_03.htm>
+Mitchell
Jason Trenouth
wrote:
> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.
>
> I am especially interested in the following:
>
> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
(with-hand-wave (:level :tsunami)
Something that has disappointed me when directly using, or hearing second-hand
about, applications written in static languages like C or even strict
languages like ML or Eiffel is that _in practice_ they don't seem to be any
more reliable than products written in dynamic languages like Common Lisp,
Smalltalk, or Dylan.
Personally I've come to think that perhaps large applications have a
non-reducible amount of complexity and dynamism. In the end your choice of
programming language and tools just defines a boundary between the
complexity/dynamism that the language implementor gets to deal with and the
complexity/dynamism that the application implementor has to deal with.
So if you design a language that restricts and constrains what can be
naturally expressed in the language then it spills over into the application,
and dynamic mechanisms end up being built by hand (hence some design
patterns). You seem to still get a significant number of bugs, but you get
them in less-supported application-specific ways. And, of course, development
takes longer and bug fixing is harder.
However, this isn't to say that laissez faire dynamism is the ultimate goal.
You still want all the compile-time checking that you can get, but it is wrong
to stop there and leave peasant programmers to build shanty town dynamism
outside the castle Gates.
)
__Jason
Paolo Amoroso
wrote:
> Common Lisp - Myths and Legends
> http://www.harlequin.com/support/lisp-info/lisp-white.html
Section "Who's Using Lisp" of this document should be updated to mention
the Deep Space 1 Remote Agent:
http://www.hq.nasa.gov/office/codei/swy99win.html
I suspect someone at Harlequin vaguely knows about the project :-)
Harley Davis
news:aI%X3.533$X5.7...@ptah.visi.com...
> I've seen references to 30% of the debugging effort in C/C++ going into
> memory issues, and in my experience they aren't all solved anyway.
> Time spent in CL with similar issues: 0%. (Well, you can do your
> own memory management in CL, and I suppose you could run into problems
> by doing so, but it's a lot easier to do and a lot easier to get right.)
This is not 100% true. Often a lot of time has to go into memory issues in
Lisp programming, but the focus is very different - in C/C++ you have to
deal with these issues to avoid having the program crash, while in Lisp you
are usually trying to optimize program performance by minimizing allocations
(and thus GC's) and trying to avoid memory leaks that cause infinite process
growth. The time is not zero, but it is significantly less than in C/C++.
> CL's integer arithmetic has the amazing property of being correct. In
> most systems, generating an integer that is out of bounds simply gives
> an incorrect result, while in some it crashes the machine. In CL, it
> slows down the processing a bit. How confident are you of the size of
> your intermediate results?
There's a large cost to bignum arithmetic that is often unnecessary. The
large majority of uses of ints in C/C++ are limited to well-bounded loops
where 100% accurate arithmetic is not required. Of course, it's nice to
have unbounded range arithmetic when needed, but it's also nice to get down
to the metal for the majority case.
> Anybody else care to name something that is (or really should be) an issue
> in C/C++ programming that is a non-issue in CL?
The generic function model is much more expressive than C++ methods and can
make lots of "design patterns" totally unnecessary or trivial in Lisp
compared with C++.
-- Harley
Liam Healy
> There's a certain irony in arguing that Lisp is faulty because it
> doesn't have static typing like C. In fact, the thing to realize is
> that in Lisp, variables do not have types; instead, EVERY LISP OBJECT
> has a type. This is what Lisp's tag bits are all about. Variables
> are just names for values (see `Lambda, the Ultimate Declarative' by
> Guy Steele).
>
> In other words, Lisp sacrifices a certain level of performance (a
> sacrifice that can often be retrieved by careful use of declarations)
> in exchange for making sure that the system knows exactly what kind of
> thing every object is. This removes the need for the programmer to
> worry about telling the system something it already knows. But, since
> people are used to thinking in terms of C, they think this is a flaw,
> when it is actually a programming aid, like garbage collection.
>
> Languages like C are flawed because they don't know what the objects
> they are representing actually are. They put the onus for dealing
> with this on the programmer and that leads to programming errors.
>
This is somewhat off the topic, but...
I have always thought of Lisp, even pre-CLOS, flavors, etc., as a
natively object-oriented language. Anything in lisp, not just
user-defined objects, are objects because they encapsulate not just
the datum (the value) but also the metadata (what the thing is; say, a
fixnum). The two together make an object. A language like C is not
object-oriented because it deals with memory locations containing
unpecified data (binary) - it's never an object because the metadata
must be carried around and managed separately.
I realize that this doesn't conform with the standard usage of the
term "object-oriented" which has more to do with methods acting on
objects, but it's an important concept that makes Lisp vastly more
usable, in my experience.
--
Liam Healy
Liam....@nrl.navy.mil
Chuck Fry
Paolo Amoroso <amo...@mclink.it> wrote:
>On Sat, 13 Nov 1999 20:11:38 +0100, jos...@lavielle.com (Rainer Joswig)
>wrote:
>> Common Lisp - Myths and Legends
>> http://www.harlequin.com/support/lisp-info/lisp-white.html
>
>Section "Who's Using Lisp" of this document should be updated to mention
>the Deep Space 1 Remote Agent:
>
> http://www.hq.nasa.gov/office/codei/swy99win.html
See also:
<http://rax.arc.nasa.gov/>
>I suspect someone at Harlequin vaguely knows about the project :-)
I would hope so! Martin Simmons is still there, last I heard.
-- Chuck, who, needless to say, is not speaking for NASA
--
Chuck Fry -- Jack of all trades, master of none
chu...@chucko.com (text only please) chuc...@home.com (MIME enabled)
Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
The addresses above are real. All spammers will be reported to their ISPs.
Rob Warnock
+---------------
| Something that has disappointed me when directly using, or hearing
| second-hand about, applications written in static languages like C
| or even strict languages like ML or Eiffel is that _in practice_ they
| don't seem to be any more reliable than products written in dynamic
| languages like Common Lisp, Smalltalk, or Dylan.
Or even "typeless" languages such as BLISS! IIRC, one of Bill Wulf's
papers on BLISS, "Why the dot?", claimed that in an analysis of programmer
errors in BLISS, even though in BLISS data itself is untyped (all data
is just machine words of bits, *operators* are typed, sort of), very few
of the errors were found to be "type errors", that is, where the programmer
interpreted the data in a variable as something other than what it was.
He attributed this to the rich set of structuring/accessing/macro facilities
in BLISS that allowed the programmer to rise above (lost of) the low-level
representational issues.
On the other hand, missing or extra "dots" [the BLISS dereferencing
operator] and misplaced semicolons [expression separators] were fairly
frequent...
-Rob
-----
Rob Warnock, 8L-846 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Tim Bradshaw
> Or even "typeless" languages such as BLISS!
This is pretty off-topic, but do you know if there's any family
relation between BLISS and BCPL? Your description of it could almost
apply to BCPL (although it didn't have any macro system to speak of).
Sadly I no longer have a machine with a BCPL compiler, because it was
kind of fun to program in.
--tim
Rob Warnock
+---------------
| * Rob Warnock wrote:
| > Or even "typeless" languages such as BLISS!
|
| This is pretty off-topic, but do you know if there's any family
| relation between BLISS and BCPL?
I don't think so, not in the sense of the well-documented evolution
from BCPL -> B -> C, say. But I strongly suspect the authors of BLISS
*knew* of BCPL, and were at least somewhat influenced by it (and also
a bunch of other things)...
B.t.w., if you want to read more, the BLISS-11 Programmers Manual is
online at <URL:http://www.dbit.com/pub/alpha/bliss11/bliss.txt>, and
in fact, that same directory contains the entire source of the BLISS-11
compiler (written in BLISS-64, though the original BLISS-11 was written
in BLISS-10).
One really nice idea I got from the BLISS compilers that I continue
to use in Scheme & CL is the notion of parsing infix languages using
a mixture of top-down recursive descent for the control structures
and simple operator precedence for the arithmetic expressions. The
"trick" is to define the control structure keywords (IF, CASE, etc.)
to be left-associative "operators" of *very* high precedence. Then things
like "a + b * if this then x + y * z else other fi - 32" are very easily
parsed into (- (+ a (* b (if this (+ x (* y z)) other))) 32)".
[The other part of that "trick" is that "stoppers" or terminators such
as "FI", "ESAC", comma, semicolon, right-parens & -brackets, etc., are
defined as "operators" of very *low* precedence, so that they "stop"
any recursively-embedded expressions and return control to the top-down
parser.]
I don't think it's any more powerful than "pure" recursive descent
in terms of the languages it parses, but it makes it a *lot* easier
to encode the grammar of the infix arithmetic sub-expressions than
the "pure" recursive descent style... (IMHO)
If you want to look at the original BLISS version of this, the routines
"lexan.bli" (routine "RUND", or Read Until Next Delimeter) and "syntax.bli"
(routine "EXPRESSION") have most of the guts. [Or if somebody wuld rather
see a piece of Scheme that does a similar (though a lot simpler) thing, I
could dig that out of some old code I have and post that...]
Obligatory (vaguely) Lisp-related note: The macro "XCTSYNTAX" in routine
EXPRESSION can be thought of as a kind of generic function dispatch that
vectors off to the parsing routine for the specific operator (in BLISS
compiler terms, "delimiter") currently in the "DEL" slot of the current
"lexical window". That is, all you have to do to add a new operator to
the compiler is add a defmethod to XCTSYNTAX with an EQL specializer
on the new operator type. (O.k., o.k., so there are about a dozen *other*
"generic functions" you have to add specialized methods to too, e.g.,
the one that builds a graph-table lexeme from the results of parsing
the operator & its arguments from the user code. Details...)
-Rob
p.s. Pardon me if this was a bit long, but most of my early learning
about compiling came from reading the BLISS-10 & BLISS-11 compilers'
source codes and Wulf et al's "The Design of an Optimizing Compiler" --
a classic, IMHO!!
Robin Popplestone
> One really nice idea I got from the BLISS compilers that I continue
> to use in Scheme & CL is the notion of parsing infix languages using
> a mixture of top-down recursive descent for the control structures
> and simple operator precedence for the arithmetic expressions. The
> "trick" is to define the control structure keywords (IF, CASE, etc.)
> to be left-associative "operators" of *very* high precedence. Then things
> like "a + b * if this then x + y * z else other fi - 32" are very easily
> parsed into (- (+ a (* b (if this (+ x (* y z)) other))) 32)".
> [The other part of that "trick" is that "stoppers" or terminators such
> as "FI", "ESAC", comma, semicolon, right-parens & -brackets, etc., are
> defined as "operators" of very *low* precedence, so that they "stop"
> any recursively-embedded expressions and return control to the top-down
> parser.]
> I don't think it's any more powerful than "pure" recursive descent
> in terms of the languages it parses, but it makes it a *lot* easier
> to encode the grammar of the infix arithmetic sub-expressions than
> the "pure" recursive descent style... (IMHO)
I used a trick like this for implementing the POP-2 compiler in 1968, and
it wasn't new then - I can't remember where we got it from, but it was floating
in non-cyber space. For those who have Poplog installed, look at
$usepop/pop/src/pop11_compile.p to see the current version by John Gibson; it
works in much the same way.
What this approach does do is make it easy to provide
a facility for users of a language thus implemented to define the precedence
of their own operators. This sort of thing (in POP-11):
define 4 A ++ B;
conspoint(xof(A)+xof(B), yof(A) + yof(B))
enddefine;
[which introduces an new infix operator "++", and gives it a value]
The ML people who wanted to provide this kind of capability while
being more conventional in their characterisation of syntax seem to
have had some problems in this respect.
Robin.
Jeff Dalton
> > Anybody else care to name something that is (or really should be) an issue
> > in C/C++ programming that is a non-issue in CL?
>
> The generic function model is much more expressive than C++ methods and can
> make lots of "design patterns" totally unnecessary or trivial in Lisp
> compared with C++.
People programming in languages such as C++ and Java *need* patterns.
Why? First, it may be quite difficult to figure out a good O-O way to
do certain things, if it must fit the kind of O-O available in those
languages. Second, if you do figure out a way to do something, it may
look like such a hopeless kludge that you can't believe that's what
good Java or C++ programmers would do. Discovering that it's actually
a design pattern reassures you that you are not such an idiot and that
you need look no further. The hopeless kludge really is what the
experts do, and you can use it with confidence.
(Anyone remember the song "Kissing with confidence", by the way?)
In the Lisp world, we actually have quite a few patterns, including
some interesting ones (e.g. method combination, mixin servers). But
we haven't done much to foreground this fact so that it's easy enough
to notice. So these other languages are the ones associated with
patterns, so far as the general interested public is concerned, and
since patterns are a good (not to mention trendy) thing, some of
this good-thingness (and with-it-ness) is reflected onto those other
languages, to their benefit, and, in effect, to our cost.
We have some better patterns, and can do a better job with some of the
usual cases (e.g. because we have multi-methods), so we ought to be
able to do pretty well here. Web pages, anyone?
BTW, re:
> There's a large cost to bignum arithmetic that is often unnecessary. The
> large majority of uses of ints in C/C++ are limited to well-bounded loops
> where 100% accurate arithmetic is not required. Of course, it's nice to
> have unbounded range arithmetic when needed, but it's also nice to get down
> to the metal for the majority case.
Fortunately, fixnums.
-- jeff
Michael Schuerig
> People programming in languages such as C++ and Java *need* patterns.
> Why? First, it may be quite difficult to figure out a good O-O way to
> do certain things, if it must fit the kind of O-O available in those
> languages. Second, if you do figure out a way to do something, it may
> look like such a hopeless kludge that you can't believe that's what
> good Java or C++ programmers would do. Discovering that it's actually
> a design pattern reassures you that you are not such an idiot and that
> you need look no further. The hopeless kludge really is what the
> experts do, and you can use it with confidence.
A pattern is definitely *not* what the experts *do*. A pattern is
something that in the past has been shown in several cases to provide a
reasonable solution to several counteracting forces. A pattern helps
with making ones mind up about how to deal with commonly occurring
situations during design. It does not prescribe a particular solution,
rather it helps you find the appropriate specific solution.
> In the Lisp world, we actually have quite a few patterns, including
> some interesting ones (e.g. method combination, mixin servers).
Those are idioms. And that isn't meant in any way to devalue them. It's
just that they're not patterns.
> We have some better patterns, and can do a better job with some of the
> usual cases (e.g. because we have multi-methods), so we ought to be
> able to do pretty well here. Web pages, anyone?
Peter Norvig has a presentation of patterns in Dylan on his site.
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/
Jeff Dalton
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>
> > People programming in languages such as C++ and Java *need* patterns.
> > Why? First, it may be quite difficult to figure out a good O-O way to
> > do certain things, if it must fit the kind of O-O available in those
> > languages. Second, if you do figure out a way to do something, it may
> > look like such a hopeless kludge that you can't believe that's what
> > good Java or C++ programmers would do. Discovering that it's actually
> > a design pattern reassures you that you are not such an idiot and that
> > you need look no further. The hopeless kludge really is what the
> > experts do, and you can use it with confidence.
>
> A pattern is definitely *not* what the experts *do*.
Really? If there are better ways to do things, why are we bothering
with these inferior patterns?
> A pattern is
> something that in the past has been shown in several cases to provide a
> reasonable solution to several counteracting forces. A pattern helps
> with making ones mind up about how to deal with commonly occurring
> situations during design. It does not prescribe a particular solution,
> rather it helps you find the appropriate specific solution.
Did I say anything about prescribing a particular solution? [No]
[Don't misunderstand my "need look no futher".]
Anyway, one way in which a pattern can help you to find an appropriate
specific solution is by reassuring you that the solution you were
considering is thought to be a reasonable way of doing things rather
than the hopeless kludge it appeared to be.
> > In the Lisp world, we actually have quite a few patterns, including
> > some interesting ones (e.g. method combination, mixin servers).
>
> Those are idioms. And that isn't meant in any way to devalue them. It's
> just that they're not patterns.
Why are they not patterns? Just because they haven't been written up
as patterns doesn't mean they aren't.
-- jd
David Hanley
I think there's a good heap of truth in ytour statement. In the modern
work enviornment, you can come up with the best, most elegant
architecture ever.. And have it tossed aside because someone
has a design which supposedly follows patterns.
Thre's nothing wrong with patterns per se. They can provide good
examples and ideas. The problem arises when developers with the
creativity of lunch meat look as them as templates and try to realize
every design effort by changing variable and classnames in the examples
from the patterns book, and critique every design by asking what
pattern it follows.
dave
Craig Brozefsky
> > A pattern is definitely *not* what the experts *do*.
>
> Really? If there are better ways to do things, why are we bothering
> with these inferior patterns?
Because the languages and organizing models being used are poor fits
for some of the problem domains encountered. Also, patterns can be a
folkloric or informal mechanism for capturing some abstractions which
the languages cannot capture because they are insufficiently flexible,
expressive or modifiable.
> Anyway, one way in which a pattern can help you to find an
> appropriate specific solution is by reassuring you that the solution
> you were considering is thought to be a reasonable way of doing
> things rather than the hopeless kludge it appeared to be.
If it looks like a kludge, and quacks like a kludge, must be a kludge.
--
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
Michael Schuerig
> schu...@acm.org (Michael Schuerig) writes:
>
> > Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
> > A pattern is definitely *not* what the experts *do*.
>
> Really? If there are better ways to do things, why are we bothering
> with these inferior patterns?
Come on. Not everything an expert does is a pattern. Experts find
patterns, experts use patterns -- others may do so as well. What makes
something a pattern is not the expert status of people involved with.
> Anyway, one way in which a pattern can help you to find an appropriate
> specific solution is by reassuring you that the solution you were
> considering is thought to be a reasonable way of doing things rather
> than the hopeless kludge it appeared to be.
What has the appearance of a kludge might be the best thing one can do
given the circumstances. Of course it can be a reasonable alternative to
change the circumstance -- for instance use another programming
language.
> > > In the Lisp world, we actually have quite a few patterns, including
> > > some interesting ones (e.g. method combination, mixin servers).
> >
> > Those are idioms. And that isn't meant in any way to devalue them. It's
> > just that they're not patterns.
>
> Why are they not patterns? Just because they haven't been written up
> as patterns doesn't mean they aren't.
Did I give the impression that being written up in some form is required
to make something a pattern? I don't think so. What makes me reluctant
to call them patterns is that they are _very_ generic and closely tied
to particular programming languages. That doesn't at all mean that
they're somehow inferior to patterns, they're just something different.
Feel free to correct me: What particular design problems are solved by
method combination and mixin servers? My impression is that they're just
handy in general.
Tim Bradshaw
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>> In the Lisp world, we actually have quite a few patterns, including
>> some interesting ones (e.g. method combination, mixin servers).
> Those are idioms. And that isn't meant in any way to devalue them. It's
> just that they're not patterns.
If they aren't then neither is most of what the GOF book describes.
--tim
Tim Bradshaw
>> > [Jeff Dalton wrote ]
>> > > In the Lisp world, we actually have quite a few patterns, including
>> > > some interesting ones (e.g. method combination, mixin servers).
> Did I give the impression that being written up in some form is required
> to make something a pattern? I don't think so. What makes me reluctant
> to call them patterns is that they are _very_ generic and closely tied
> to particular programming languages.
I don't see that either method combination or mixin servers are tied
to particular languages at all. It possibly happens to be the case
that only Lisp-family language have these things, but that's because
lisp is just way ahead of the field in this stuff.
> That doesn't at all mean that
> they're somehow inferior to patterns, they're just something different.
> Feel free to correct me: What particular design problems are solved by
> method combination and mixin servers? My impression is that they're just
> handy in general.
I think things like this solve a lot of problems that typically get
solved by various patterns in other languages. Perhaps they aren't
patterns because they are too broad (but this again seems to go
against various other things which are seen as patterns but are also
quite broad).
If they aren't patterns, then it's because they are *better* than
patterns (because they remove the need for many patterns). And
bizarrely this is a *disadvantage*, because people don't listen when
you explain to your explanation of why don't need pattern x in Lisp
beyond the fact that Lisp doesn't do pattern x but C++ (say) does.
More features is better, even if they are useless.
--tim
Michael Schuerig
> * Michael Schuerig wrote:
> >> > [Jeff Dalton wrote ]
> >> > > In the Lisp world, we actually have quite a few patterns, including
> >> > > some interesting ones (e.g. method combination, mixin servers).
>
> > Did I give the impression that being written up in some form is required
> > to make something a pattern? I don't think so. What makes me reluctant
> > to call them patterns is that they are _very_ generic and closely tied
> > to particular programming languages.
>
> I don't see that either method combination or mixin servers are tied
> to particular languages at all.
Well, factually they are.
> It possibly happens to be the case
> that only Lisp-family language have these things, but that's because
> lisp is just way ahead of the field in this stuff.
No arguing here.
> > Feel free to correct me: What particular design problems are solved by
> > method combination and mixin servers? My impression is that they're just
> > handy in general.
>
> I think things like this solve a lot of problems that typically get
> solved by various patterns in other languages. Perhaps they aren't
> patterns because they are too broad
Yes, exactly, they are _not_ patterns because they are too braod. Take
multi-methods, they easily and elegantly make the Observer pattern
superfluous. But, of course, multi-methods do a lot more.
> (but this again seems to go
> against various other things which are seen as patterns but are also
> quite broad).
It's the other way round: These other things ought not to be called
patterns.
> If they aren't patterns, then it's because they are *better* than
> patterns (because they remove the need for many patterns).
It seems to me that your conception of patterns is too narrowly tied to
the catalog presented in Gamma et al.'s "Design Patterns". Jim Coplien
is even collecting Organizational Patterns. In a sense, patterns are
condensed expert knowledge.
> And
> bizarrely this is a *disadvantage*, because people don't listen when
> you explain to your explanation of why don't need pattern x in Lisp
> beyond the fact that Lisp doesn't do pattern x but C++ (say) does.
> More features is better, even if they are useless.
The best I can say is: Try to avoid those people. If you can't then show
them how incredibly easy those patterns are implemented in Lisp. In
Lisp, too, you have to decide to solve the problem in that particular
way -- and that's the heart of the pattern.
Tim Bradshaw
>>
>> I don't see that either method combination or mixin servers are tied
>> to particular languages at all.
> Well, factually they are.
What I meant was that only lisp-family languages happen to have these
things provided. If, for instance, I were to write a book describing
techniques for doing method combination in Java, would it be a pattern
or not?
> Yes, exactly, they are _not_ patterns because they are too braod.
So (I know I'm harking on at the GOF book, but it's common ground),
why is, say, iterator *not* broad? It does a lot.
> It seems to me that your conception of patterns is too narrowly tied to
> the catalog presented in Gamma et al.'s "Design Patterns". Jim Coplien
> is even collecting Organizational Patterns. In a sense, patterns are
> condensed expert knowledge.
But that's just *exactly* what method combination is! Experts
discovered that this stuff was useful and provided it in the language.
It seems to me that the problem is actually different: design patterns
are ways of describing techniques which are commonly useful but which
are *not* provided by the language you are using. So if I, again,
wrote this mythical book describing a clever way of doing method
combination by hand in Java or C++, this would be a pattern, but if I
design a language which provides this, it isn't.
So, from this viewpoint, a (software) pattern is simply an artifact of
the deficiencies of various implementation languages. So patterns are
of limited use since they won't be able to be used usefully to
communicate between languages with different sets of deficiencies.
Currently they are useful because there is a linguistic monoculture
(if you regard Java and C++ as the same language, which is pushing it
I know, but bear with me), so patterns have communicative uses. I
don't think that's right -- there's more to them than that I think,
although what is somewhat elusive. Richard Gabriel seems to have some
idea about this, but he can't really describe it right I think.
--tim
PS examples of the final point:
In C++ and Java you have built in (language-provided)
mechanisms for control of access to object slots, while CLOS
does not. So various patterns that might be used to do this
in CLOS-based programs are just not relevant to Java and C++.
In Lisp there's a common & useful pattern which relates a
WITH-x macro and a CALL-WITH-x function:
(with-saved-frobnicators (x) ...code...)
and
(call-with-saved-frobnicators (lambda (x) ..code...))
That pattern just doesn't make sense in languages like C++ and
Java which don't have anonymous functions & proper scoping.
Jeff Dalton
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>
> > schu...@acm.org (Michael Schuerig) writes:
> >
> > > Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>
> > > A pattern is definitely *not* what the experts *do*.
> >
> > Really? If there are better ways to do things, why are we bothering
> > with these inferior patterns?
>
> Come on. Not everything an expert does is a pattern.
That's not what I said. The relevant question is: if you're trying
to do something for which there's a pattern in the pattern literature,
and you're using the sort of language the pattern-authors had in mind
for that pattern (which will typically be C++ or Java), then is it
reasonable to conclude that the pattern is thought to be a good way
of doing what you're trying to do -- a way that even experts might
use?
If experts in fact do something else in such cases, one has to wonder
just why patterns are thought to be such a good thing.
> Experts find
> patterns, experts use patterns -- others may do so as well.
Just so.
> What makes
> something a pattern is not the expert status of people involved with.
And I have never said otherwise.
> > Anyway, one way in which a pattern can help you to find an appropriate
> > specific solution is by reassuring you that the solution you were
> > considering is thought to be a reasonable way of doing things rather
> > than the hopeless kludge it appeared to be.
>
> What has the appearance of a kludge might be the best thing one can do
> given the circumstances.
Exactly.
> Of course it can be a reasonable alternative to
> change the circumstance -- for instance use another programming
> language.
I agree.
> > > > In the Lisp world, we actually have quite a few patterns, including
> > > > some interesting ones (e.g. method combination, mixin servers).
> > >
> > > Those are idioms. And that isn't meant in any way to devalue them. It's
> > > just that they're not patterns.
> >
> > Why are they not patterns? Just because they haven't been written up
> > as patterns doesn't mean they aren't.
>
> Did I give the impression that being written up in some form is required
> to make something a pattern?
I was making a guess. Mixin server seems pretty straightforwardly a
pattern to me. It wasn't clear to me what, apart from unfamiliarity,
would cause someone to think it was not a pattern.
Method combination is perhaps trickier, because strictly speaking it's
a language feature, and hence strictly speaking not a pattern. Maybe
it's easier to think of it as a meta-pattern.
> I don't think so. What makes me reluctant
> to call them patterns is that they are _very_ generic and closely tied
> to particular programming languages.
But much of the pattern literature is tied pretty closely to languages
like C++ and Java.
> That doesn't at all mean that
> they're somehow inferior to patterns, they're just something different.
> Feel free to correct me: What particular design problems are solved by
> method combination and mixin servers? My impression is that they're just
> handy in general.
Humm. A lot of patterns seem of similar generality to me.
-- jeff
Jeff Dalton
> * Michael Schuerig wrote:
> >>
> >> I don't see that either method combination or mixin servers are tied
> >> to particular languages at all.
>
> > Well, factually they are.
>
> What I meant was that only lisp-family languages happen to have these
> things provided.
Mixin servers aren't provided, at least not on Common Lisp or any
other Lisp I've used recently enough for me to remember such details.
They're a kind of factory.
> > Yes, exactly, they are _not_ patterns because they are too braod.
Mixin server is narrower than factory.
> > It seems to me that your conception of patterns is too narrowly tied to
> > the catalog presented in Gamma et al.'s "Design Patterns". Jim Coplien
> > is even collecting Organizational Patterns. In a sense, patterns are
> > condensed expert knowledge.
> But that's just *exactly* what method combination is! Experts
> discovered that this stuff was useful and provided it in the language.
The pattern world is ideological. "Pattern" can be generalized to
cover organizational patterns, and in lots of other ways, but as soon
as you try to generalize to include programming patterns that fit well
with languages outside the ones usually associated with patterns, but
not very well with the languages within, you meet resistance.
The exact reason will take work to discover, because it's the
intuition that they're not patterns that comes first, with the
reasons as a kind of adaptable rationalization.
The flip side of this is that there are people in the Lisp world who
say we don't need patters -- patterns are for those other, losing
languges. My view is that those people are partly right: we don't
*need* patterns in quite the same way or to the extent that people
working in C++ or Java do. But where this ought to be an advantage
(becuse we can do various things more easily), it often functions
instead as a disadvantage (because people think they ought to use
patterns, and it's not clear how that works in Lisp).
> It seems to me that the problem is actually different: design patterns
> are ways of describing techniques which are commonly useful but which
> are *not* provided by the language you are using.
There's something to that. Norvig, on his web pages mentioned in an
earlier message in this thread, says subroutine call used to be a
pattern.
-- jd
Michael Schuerig
> * Michael Schuerig wrote:
> >>
> >> I don't see that either method combination or mixin servers are tied
> >> to particular languages at all.
>
> > Well, factually they are.
>
> What I meant was that only lisp-family languages happen to have these
> things provided. If, for instance, I were to write a book describing
> techniques for doing method combination in Java, would it be a pattern
> or not?
I'm not really sure about it, but I think it will very much depend on
your description
> > Yes, exactly, they are _not_ patterns because they are too braod.
>
> So (I know I'm harking on at the GOF book, but it's common ground),
> why is, say, iterator *not* broad? It does a lot.
Oh dear. Yes, you're right, of course. But I would hardly call Iterator
a pattern even though it's in the GOF book. It's an idiom at best. I
must admit though, that perception may have changed with time.
> It seems to me that the problem is actually different: design patterns
> are ways of describing techniques which are commonly useful but which
> are *not* provided by the language you are using. So if I, again,
> wrote this mythical book describing a clever way of doing method
> combination by hand in Java or C++, this would be a pattern, but if I
> design a language which provides this, it isn't.
Yes. I wanted to write this in my previous posting, but I still can't
remember who said that a pattern is something that was left out of the
language.
> So, from this viewpoint, a (software) pattern is simply an artifact of
> the deficiencies of various implementation languages. So patterns are
> of limited use since they won't be able to be used usefully to
> communicate between languages with different sets of deficiencies.
> Currently they are useful because there is a linguistic monoculture
> (if you regard Java and C++ as the same language, which is pushing it
> I know, but bear with me), so patterns have communicative uses. I
> don't think that's right -- there's more to them than that I think,
> although what is somewhat elusive. Richard Gabriel seems to have some
> idea about this, but he can't really describe it right I think.
Richard Gabriel basically follows Christopher Alexander, as far as I
remember from reading his "Patterns of Software". In that regard he's in
a boat with Jim Coplien and a lot of others.
I don't agree with your statement that, more or less, a pattern is a
cure for a weakness in the language. A few weeks ago there was a short
thread in this group concerned with "Lisp spirit". From what little I
understand of it, this is exactly what could be captured by patterns.
Robert Monfera
> Mixin servers aren't provided, at least not on Common Lisp or any
> other Lisp I've used recently enough for me to remember such details.
> They're a kind of factory.
Do you mean something like generating classes by mixing of (inheriting
from) other classes programmatically? My code is doing that - it is
mixing, and it is a kind of factory. If you meant something else,
please specify so that it could be discussed.
Robert
Tim Bradshaw
> Mixin servers aren't provided, at least not on Common Lisp or any
> other Lisp I've used recently enough for me to remember such details.
> They're a kind of factory.
OK, I meant method combination really.
By a mixin server do you mean the oaklisp thing where you could say
`give me the class that mixes these classes' to some thing (the mixin
server I guess) and it provide such such a class, creating it if need
be? That's what I've been assuming you meant... It's annoying that
you can't quite do this in CL without either some more CLOS MOP or
EVAL...
--tim
Michael Schuerig
> schu...@acm.org (Michael Schuerig) writes:
>
> > Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
> >
> The relevant question is: if you're trying
> to do something for which there's a pattern in the pattern literature,
> and you're using the sort of language the pattern-authors had in mind
> for that pattern (which will typically be C++ or Java), then is it
> reasonable to conclude that the pattern is thought to be a good way
> of doing what you're trying to do -- a way that even experts might
> use?
A pattern doesn't take away the need to think. Usually, a pattern
description lists the forces that may apply in a particular case and
provide one or more solutions for dealing with particular combinations
of forces. You have judge for yourself if and how it applies to the case
at hand.
> If experts in fact do something else in such cases, one has to wonder
> just why patterns are thought to be such a good thing.
Do they? A good expert will probably go through at least the
considerations mentioned in the pattern description.
> But much of the pattern literature is tied pretty closely to languages
> like C++ and Java.
> Humm. A lot of patterns seem of similar generality to me.
Then just rename then internally to idioms and, if necessary, keep outer
appearance up.
BTW, what do you think of "Value + Quantity"? There you don't carry
around plain values, but their units as well. It's some kind of
home-made manifest typing. I'd be surprised if something like this is
not used in the Lisp community.
Rob Warnock
+---------------
| > If they aren't patterns, then it's because they are *better* than
| > patterns (because they remove the need for many patterns).
|
| the catalog presented in Gamma et al.'s "Design Patterns". Jim Coplien
| is even collecting Organizational Patterns. In a sense, patterns are
| condensed expert knowledge.
Indeed. See Richard Gabriel's excellent rant in his book "Patterns of
Software" against the Gang-of-Four's freezing of Christopher Alexander's
notion of patterns into some rigid identification with class libraries.
Nothing could be further from the truth.
IMHO, a pattern is *any* recognizable meta-structure that provides useful
shape to the otherwise bewildering chaos of design space, e.g., Alexander's
"alcove pattern" in designing shared living spaces (an example discussed
at length in Gabriel's book).
+---------------
| In Lisp, too, you have to decide to solve the problem in that particular
| way -- and that's the heart of the pattern.
+---------------
To me, the heart of the whole "pattern" notion is that a pattern is *not*
a rigid template -- it has to be adapted to the "local conditions" of the
solution space of the problem being solved. And a given solution often
involves the use of more than one pattern, and each has to be adapted/
tweaked/bent/evolved/merged to fit harmoniously with the others, something
that is simply impossible with pre-defined libraries/classes/templates.
-Rob
Marco Antoniotti
I have been following this thread about patterns and wondered. Has
anybody anything to comment about Gabriel's book "Patterns of
Software"?
All in all I formed the idea that "patterns" are necessary as a
communication mean. If for no other reason than that that many "new"
programmers use that terminology (and UML as well, just to cite
another example). I have many more doubts about the specific patterns
per se. The only truly recognizable one that I always found in my
programmign experience is the so-called "Visitor" pattern.
Just my 0.02 EU.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Michael Schuerig
> I have been following this thread about patterns and wondered. Has
> anybody anything to comment about Gabriel's book "Patterns of
> Software"?
Yes: Read it. Not so much for gaining technical knowledge, but rather
because it's very interesting. In particular when he tells the story of
his company.
> All in all I formed the idea that "patterns" are necessary as a
> communication mean. If for no other reason than that that many "new"
> programmers use that terminology (and UML as well, just to cite
> another example). I have many more doubts about the specific patterns
> per se.
Yes, on all counts. Pattern speak is a powerful way of getting onto a
higher level of abstraction.
> The only truly recognizable one that I always found in my
> programmign experience is the so-called "Visitor" pattern.
In a language with multiple dispatch?
Michael Schuerig
Tim Bradshaw
> To me, the heart of the whole "pattern" notion is that a pattern is *not*
> a rigid template -- it has to be adapted to the "local conditions" of the
> solution space of the problem being solved. And a given solution often
> involves the use of more than one pattern, and each has to be adapted/
> tweaked/bent/evolved/merged to fit harmoniously with the others, something
> that is simply impossible with pre-defined libraries/classes/templates.
I understand this (and I think that Michael Schuerig didn't quite
appreciate what I was getting at in the message you're following up
to, probably because I expressed myself badly).
What I'm interested in is the communicative use of patterns, and in
particular that they might not have as much use as people think in the
software world.
In architecture (say), you can talk about the foo pattern, and it's
useful because it seems (to me as a non-architect) unlikely that some
new kind of architecture will turn up which utilises what was once foo
pattern somehow directly. I think this is `obvious' if only because
the previous sentence immediately strikes me as bizarre.
But in software you might be struggling away in language x and end up
inventing a whole bunch of patterns, only to discover that language y
has constructs in the language which implement these `patterns'. A
good example might be subroutine call -- if you've ever written 1802
code you'll appreciate that this could be regarded as a pattern.
Lisp is a good example of a language which has constructs which
implement things that are often regarded as patterns of course.
But now there's a problem. If you can formalise the description of
some proposed `pattern', then you can invent a language which talks
about it directly -- because programming languages really just *are*
formal descriptions of things. And of course Lisp is the language
you'd do that in because Lisp is kind of about this metalinguistic
stuff in some sense.
But if you can have it directly in some language then it isn't a
pattern (they say).
So what you are left with is things whose description you can *not*
formalise. Which is kind of OK, because it's quite similar to the
architectural stuff -- it's certainly extraordinarily hard to describe
what an `alcove' is in some formal way. And probably this is related
to the whole `quality without a name' stuff.
I think such a definition basically rules out almost all the things
held up as software design patterns I've seen. Which is OK, because
none of them have really seemed very convincing to me.
But the problem is now that, if patterns are things that you can't
really describe, they are *also* things you can't reliably
communicate, or at least not without doing so face to face. Which,
again, is OK, but it really makes me wonder what use they are in the
current environment of non-expert programmers who really need a lot of
explicit help for things, not hand-waving stuff which you can never be
sure that they've understood.
(This whole non-describability thing is very like how physicists (and
probably other scientists) work -- if you get physicists talking to
each other you'll hear a whole lot of `g mu nu' type stuff and lots of
equations will get written down, but half the time what's actually
going on -- in my experience which is now old -- is that they're
trying to get across something which is probably a pattern in the
proper sense (if I understand the proper sense), and which is not
really describable.)
--tim
Michael Schuerig
> I understand this (and I think that Michael Schuerig didn't quite
> appreciate what I was getting at in the message you're following up
> to, probably because I expressed myself badly).
>
> What I'm interested in is the communicative use of patterns, and in
> particular that they might not have as much use as people think in the
> software world.
I highly appreciate the communicative use of patterns. But my focus in
this discussion so far has not been on it.
> But now there's a problem. If you can formalise the description of
> some proposed `pattern', then you can invent a language which talks
> about it directly -- because programming languages really just *are*
> formal descriptions of things. And of course Lisp is the language
> you'd do that in because Lisp is kind of about this metalinguistic
> stuff in some sense.
Here you are more or less talking about idioms.
> But if you can have it directly in some language then it isn't a
> pattern (they say).
You can't really have a pattern directly in the language. The language
itself does not tell you when to use whatever cool feature it provides.
A pattern describing its application can. It's just that the
implementation of some of those patterns is ridiculously easy in some
languages.
> I think such a definition basically rules out almost all the things
> held up as software design patterns I've seen. Which is OK, because
> none of them have really seemed very convincing to me.
Okay. That might be because the problems never occurred to you or the
solutions seemed trivial.
> But the problem is now that, if patterns are things that you can't
> really describe, they are *also* things you can't reliably
> communicate, or at least not without doing so face to face.
You can. But, as I said, the interesting part is not in the code, but in
the identification and trading off of relevant forces.
Have a look at pattern descriptions beyond the GOF book. Skim through
the PLoP and EuroPLoP proceedings. <http://www.cetus-links.org/> is
probably a good place to start the search.
> (This whole non-describability thing is very like how physicists (and
> probably other scientists) work -- if you get physicists talking to
> each other you'll hear a whole lot of `g mu nu' type stuff and lots of
> equations will get written down, but half the time what's actually
> going on -- in my experience which is now old -- is that they're
> trying to get across something which is probably a pattern in the
> proper sense (if I understand the proper sense), and which is not
> really describable.)
Maybe the physicist ought to struggle harder to make their patterns of
thought explicit.
Tim Bradshaw
> Maybe the physicist ought to struggle harder to make their patterns of
> thought explicit.
I give up. You've completely failed to appreciate what I'm getting
at I'm afraid.
--tim
William Deakin
> I have been following this thread about patterns and wondered. Has
> anybody anything to comment about Gabriel's book "Patterns of Software"?
It's a good book: It's got a lot of autobiography, about school, college,
running a lisp compiler house and stuff like writing poetry. It's also got
a number of articles about Pattern Languages, looking at organic ideas of
growth and patterns with regards to its applications in architecture and
software engineering. This is well worth reading (IMHO). It also has
essays about problems of patterns, libraries and OO as a silver bullet and
has a `new' edition of the `Worse is Better' essay. I liked it and would
recommend reading it, even if it's just to look at why at a certain Lisp
compiler vendor went pear-shaped when it started dabbling in the muddied
world of c++. But take this with a pinch of salt, this is a very
subjective and personal opinion ;)
Best Regards,
:) will
Marco Antoniotti
schu...@acm.org (Michael Schuerig) writes:
> Marco Antoniotti <mar...@parades.rm.cnr.it> wrote:
...
> > The only truly recognizable one that I always found in my
> > programmign experience is the so-called "Visitor" pattern.
>
> In a language with multiple dispatch?
>
In the sense that the "Visitor Pattern" - AFAIU - is really about traversing
graph structures while "doing something" at each node and/or vertex.
Multiple dispatch here just makes the actual implementation much easier.
Aaron Gross
> I have been following this thread about patterns and wondered. Has
> anybody anything to comment about Gabriel's book "Patterns of
> Software"?
I wasn't convinced by all his stuff about patterns and habitability,
even though I loved Christopher Alexander's _A Pattern Language_. I
think some of the philosophy in _Patterns of Software_ is really
opposed to that of Paul Graham's _On Lisp_, and I prefer the latter.
I posted an overly-long message about this to comp.lang.lisp a couple
years ago (no followups). Since you asked for comments...I went and
dug it up. Here's a re-post.
----------------------------- RE-POST ------------------------------
Erik Naggum <er...@naggum.no> writes:
> see Richard P. Gabriel: Patterns of Software for an excellent
> treatment of the pros and cons of abstraction. I found it very
> refreshing and clear.
I skimmed over this recently, and I also thought it was refreshing,
although I'm still skeptical. I also read Paul Graham's "ANSI Common
Lisp" and skimmed through his "On Lisp", and I think there's a real
conflict between Gabriel's philosophy and Graham's.
One of Graham's main justifications for abstracting everything you can
get your hands on is that it makes the code shorter ("denser") and
consequently easier to understand. Gabriel acknowledges that the
non-abstract version is "harder to type" and "just plain longer"
(p. 29), but says that this problem "goes away with a well-designed
programming environment or doesn't matter at all when you consider the
habitability gains from using an easily understood program."
As an example (p. 28), Gabriel gives a typical call to the CL function
MISMATCH:
(mismatch sequence list :from-end t
:start1 20 :start2 40
:end1 120 :end2 140 :test #'baz)
compared with the nine-line pattern (which I don't want to type -- you
can write it yourself) that does the same thing with LET, REVERSE,
FLET, and LOOP. He implies that the nine-line version is easier to
understand: If you're familiar with the pattern, you can recognize it
immediately, and if you're not, you can understand it by reading
it. The MISMATCH example can be understood only by understanding the
function name and the meanings of the keywords.
I find this very unconvincing. I'm not an experienced Lisp programmer,
and I don't recognize the un-abstracted pattern immediately. I can
understand it by reading it, but it's easier for me to guess what the
MISMATCH example does, since the function is well-named and I'm
familiar with the conventions (patterns) involving :from-end, :start,
:end, and :test keywords. Failing this, I can always look at the
HyperSpec. I'm curious: Is there anyone out there other than Gabriel
who would prefer to see the nine lines of code instead of the call to
MISMATCH?
In an earlier example (p. 26), Gabriel considers the problem of
MAPCARing a function to a list and calculating the list's length at
the same time. The most abstract solution is also extremely
inefficient:
(let ((result (mapcar f list))
(len (length list)))
...)
Gabriel suggests (and then rejects) that one could replace this with
optimized code, and then the programming environment could display the
unoptimized version. This version "correctly respects the abstraction
of both operations...but it incorrectly overemphasizes abstraction
because the un-abstracted but common-pattern code is just fine:"
(let ((length 0)
(let ((result
(mapcar
#'(lambda (x)
(incf length)
(f x))
list)))
...))
Again, I'm not convinced. My guess is that Paul Graham would have
written a MAP-WITH-LENGTH utility to abstract out this pattern. Even
though the above pattern is instantly recognizable (even to a novice
like me), I'd rather see a one-line call to MAP-WITH-LENGTH, if for no
other reason than that it makes the code shorter. But maybe that's
just because I've been brainwashed by Paul Graham's books.
I know I didn't do justice to Gabriel's arguments here; I tried to
summarize without distorting, but I also omitted some other arguments
he makes concerning the over-use of abstraction. Still, I see Gabriel
and Graham as representing two opposing points of view, and I'm still
not convinced by Gabriel's somewhat heretical claims. I look forward
to hearing opinions of other Lisp programmers who are more experienced
than I am.
William Deakin
> Tim Bradshaw wrote:
>
> > (This whole non-describability thing is very like how physicists (and
> > probably other scientists) work -- if you get physicists talking to
> > each other you'll hear a whole lot of `g mu nu' type stuff and lots of
> > equations will get written down, but half the time what's actually
> > going on -- in my experience which is now old -- is that they're
> > trying to get across something which is probably a pattern in the
> > proper sense (if I understand the proper sense), and which is not
> > really describable.)
>
> Maybe the physicist ought to struggle harder to make their patterns of
> thought explicit.
I agree with Tim and think you are missing the point here. Maybe the
physicist (scientist, person) should stuggle harder to make their pattern
(sic) of thought more explicit. But what do you do if you are talking about
things that are conceptually difficult to grasp and have never (or are
rarely) been thought about before? The process of writing drawing pictures,
writing down equations and muttering is the best you can do to try and
communicate what you want to.
An obvious example is from solid-state physics: certain lyotropic materials
have an Ia3d group structure. I believe this to be a `pattern'. It describes
a large number of materials and is directly related the physical properties
of the material. But I defy anyone to try describe what this means in terms
of the mechanical or optical properties of the material without resorting to
pen and paper and waving of hands and such like.
Another example that springs to mind is the `pattern' describing electrons
in a super-conductor (BCS if I remember correctly). This is a pattern as
applied to liquid-crystals because it gives a model describing the structure
of the ferroelectric smectic-C phase (used in a fair number of large LC
displays).
These are by no means easy things to explain in detail. They describe
something that I think is `quality without a name', beautiful mathematical
abstraction the describes and model nature. This may miss Tim's point about
non-describability and what `quality without a name' is. As these systems
can be described and their descriptions are extremely explicit but the
meaning of these patterns is less explicit. But these description can (but
not simply) answer questions such as: what do the structure look like down a
microscope? apply an electric-field? or apply a shearing stress?
Best Regards,
:) will
William Deakin
> But now there's a problem. If you can formalise the description of
> some proposed `pattern', then you can invent a language which talks
> about it directly -- because programming languages really just *are*
> formal descriptions of things. And of course Lisp is the language
> you'd do that in because Lisp is kind of about this metalinguistic
> stuff in some sense.
>
> But if you can have it directly in some language then it isn't a
> pattern (they say).
This then would appear to boil down to a philosophical naming question: just
because I have called something a duck, and it conforms to my duck model
(looking and moving like a duck, quacking &c) is it this meta-duck really a
duck?
Best Regards,
:) will
Antonio Leitao
[...]
Aaron> In an earlier example (p. 26), Gabriel considers the problem of
Aaron> MAPCARing a function to a list and calculating the list's length at
Aaron> the same time. The most abstract solution is also extremely
inefficient>
Aaron> (let ((result (mapcar f list))
Aaron> (len (length list)))
Aaron> ...)
Aaron> Gabriel suggests (and then rejects) that one could replace this with
Aaron> optimized code, and then the programming environment could display the
Aaron> unoptimized version. This version "correctly respects the abstraction
Aaron> of both operations...but it incorrectly overemphasizes abstraction
Aaron> because the un-abstracted but common-pattern code is just fine:"
Aaron> (let ((length 0)
Aaron> (let ((result
Aaron> (mapcar
Aaron> #'(lambda (x)
Aaron> (incf length)
Aaron> (f x))
Aaron> list)))
Aaron> ...))
I wouldn't consider the first version "extremely inefficient". In
fact, the mapcar should be dominant and the difference should be
minimal. A small experience shows us that the results are quite the
opposite of the expected.
(defun test1 (f list)
(let ((result (mapcar f list))
(length (length1 list)))
(values result length)))
(defun test2 (f list)
(let ((length 0))
(let ((result
(mapcar #'(lambda (x)
(incf length)
(funcall f x))
list)))
(values result length))))
Using a list with one million numbers, I got in ACL 5.0
(time (test1 #'1+ *list*))
; cpu time (non-gc) 430 msec user, 40 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 430 msec user, 40 msec system
; real time 485 msec
; space allocation:
; 1,000,004 cons cells, 0 symbols, 32 other bytes, 0 static bytes
(time (test2 #'1+ *list*))
; cpu time (non-gc) 550 msec user, 110 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 550 msec user, 110 msec system
; real time 3,294 msec
; space allocation:
; 1,000,003 cons cells, 0 symbols, 32 other bytes, 0 static bytes
(I made several tries and the results are that test1 is always faster
than test2 (modulo gc)).
This is puzzling. Maybe the length function is much faster than
traveling along the list and incrementing a counter, so I defined my
own length:
(defun length1 (list)
(let ((count 0))
(dolist (x l count)
(incf count))))
Using length1 now, we have:
(defun test1 (f list)
(let ((result (mapcar f list))
(length (length1 list)))
(values result length)))
(time (test1 #'1+ *list*))
; cpu time (non-gc) 500 msec user, 20 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 500 msec user, 20 msec system
; real time 515 msec
; space allocation:
; 1,000,004 cons cells, 0 symbols, 32 other bytes, 0 static bytes
It's still faster than the "optimized" version that travels the list
only one (Again, I repeated the test several times and the results are
consistent). Notice that I didn't use any declarations. Probably the
extra function call for the anonymous lambda is responsible for the
difference.
Maybe Franz can comment on this.
Aaron> Again, I'm not convinced. My guess is that Paul Graham would have
Aaron> written a MAP-WITH-LENGTH utility to abstract out this pattern. Even
Aaron> though the above pattern is instantly recognizable (even to a novice
Aaron> like me), I'd rather see a one-line call to MAP-WITH-LENGTH, if for no
Aaron> other reason than that it makes the code shorter. But maybe that's
Aaron> just because I've been brainwashed by Paul Graham's books.
Aaron> I know I didn't do justice to Gabriel's arguments here; I tried to
Aaron> summarize without distorting, but I also omitted some other arguments
Aaron> he makes concerning the over-use of abstraction. Still, I see Gabriel
Aaron> and Graham as representing two opposing points of view, and I'm still
Aaron> not convinced by Gabriel's somewhat heretical claims. I look forward
Aaron> to hearing opinions of other Lisp programmers who are more experienced
Aaron> than I am.
You are already restricting the universe of possible responders.
Although I might not belong to that universe, I would like to make a
few comments.
For me, abstractions are extremely usefull, but as the number of
abstractions grows it becomes harder and harder to remember all of
them. Sometimes, it's preferable to have just a dozen of easily
understood and combinable abstractions than to have undreds of them
very hard to remember. As long as I can write simple combinations of
these abstractions, I do not jump into defining more and more
abstractions.
As an example, I developped high-order functions to deal with sets in
Common Lisp. I had mappings, foldings, filters, etc. Although most
of the time I was using these functions in combination, such as
folding after mapping after filtering, I usually prefered to leave the
combination explicit than to write a super-powerful
fold-after-map-after-filter that accepts several arguments and does
everything at the same time at warp speed.
In this case, the combination of smaller abstractions makes more sense
than a bigger abstraction. The speed issue can be solve with
compiler-macros.
OTOH, there are cases where I really prefer to see a new abstraction.
Code with side effects is such an example. Your MAP-WITH-LENGTH
example is, too me, much preferable to the mapcar combined with
side-effects.
Antonio.
Jeff Dalton
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>
> > schu...@acm.org (Michael Schuerig) writes:
> >
> > > Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
> > >
> > The relevant question is: if you're trying
> > to do something for which there's a pattern in the pattern literature,
> > and you're using the sort of language the pattern-authors had in mind
> > for that pattern (which will typically be C++ or Java), then is it
> > reasonable to conclude that the pattern is thought to be a good way
> > of doing what you're trying to do -- a way that even experts might
> > use?
>
> A pattern doesn't take away the need to think. Usually, a pattern
> description lists the forces that may apply in a particular case and
> provide one or more solutions for dealing with particular combinations
> of forces. You have judge for yourself if and how it applies to the case
> at hand.
Of course.
But consider a fairly standard example. Imagine someone who's been
using a language that has multi-methods (dynamic selection on > 1 arg)
and who starts using Java, which lacks that feature. Suppose they're
trying to deal with something that would be handled straightforwardly
using multi-methods, and they're wondering how to do it in an O-O way
in Java. After some messing around, they figure out a "double
dispatch" technqiue that will do the job, but it doesn't look like a
very good solution. Indeed, they think it looks like a kludge.
They think "there must be a better way -- why can't I find it?".
But then they start reading the patterns literature and discover that
it's actually the visitor pattern.
My view is that they ought to feel a bit happier about what they've
been doing at that point, because the seeming kludge is actually
thought to be a reasonably good way of doing things.
But then they talk with Michael Schuerig who says some things they
find confusing. For instance: "A pattern is definitely *not* what the
experts *do*." That makes it sound like the experts might have some
better ways of doing things, ways that are, for some reason, not
patterns. Though M.S. also says that experts use patterns, it
sounds like this is not an at all straightforward thing and that
one ought to be very cautious about this technique that turned out
to be the visitor pattern.
> > Humm. A lot of patterns seem of similar generality to me.
>
> Then just rename then internally to idioms and, if necessary, keep outer
> appearance up.
Why would I want to rename them? I have no objection to calling them
patterns, or to thinking of them as patterns.
(BTW, where Gabriel has complained that the Gang of Four book has
too narrow a notion of patterns, you seem to think its notion is
too broad, that it includes things that are not patterns at all,
but instead idioms. For whatever reason, I find Gabriel's view
much easier to understand.)
> BTW, what do you think of "Value + Quantity"? There you don't carry
> around plain values, but their units as well. It's some kind of
> home-made manifest typing. I'd be surprised if something like this is
> not used in the Lisp community.
Probably. I think there was a version of Scheme used for something
related to (I think) SGML that had values with units.
-- jeff
Jeff Dalton
> * Jeff Dalton wrote:
> > Mixin servers aren't provided, at least not on Common Lisp or any
> > other Lisp I've used recently enough for me to remember such details.
> > They're a kind of factory.
> OK, I meant method combination really.
> By a mixin server do you mean the oaklisp thing where you could say
> `give me the class that mixes these classes' to some thing (the mixin
> server I guess) and it provide such such a class, creating it if need
> be? That's what I've been assuming you meant...
Yes, that's it. Or it could give you an instance instead. (I forget
exactly what's in Oaklisp.)
> It's annoying that
> you can't quite do this in CL without either some more CLOS MOP or
> EVAL...
Yes. A functional version of all the main CLOS macros ought to be
in the language, but most of them seemed to be relegated to the MOP
and left out of the standard.
-- jeff
Michael Schuerig
> As an example, I developped high-order functions to deal with sets in
> Common Lisp. I had mappings, foldings, filters, etc. Although most
> of the time I was using these functions in combination, such as
> folding after mapping after filtering, I usually prefered to leave the
> combination explicit than to write a super-powerful
> fold-after-map-after-filter that accepts several arguments and does
> everything at the same time at warp speed.
I'm curious, is fold-after-map-after-filter really a useful,
"understandable" abstraction?
Michael Schuerig
> Michael Schuerig wrote:
>
> > Tim Bradshaw wrote:
> >
> > > (This whole non-describability thing is very like how physicists (and
> > > probably other scientists) work -- if you get physicists talking to
> > > each other you'll hear a whole lot of `g mu nu' type stuff and lots of
> > > equations will get written down, but half the time what's actually
> > > going on -- in my experience which is now old -- is that they're
> > > trying to get across something which is probably a pattern in the
> > > proper sense (if I understand the proper sense), and which is not
> > > really describable.)
> >
> > Maybe the physicist ought to struggle harder to make their patterns of
> > thought explicit.
>
> I agree with Tim and think you are missing the point here. Maybe the
> physicist (scientist, person) should stuggle harder to make their pattern
> (sic) of thought more explicit. But what do you do if you are talking about
> things that are conceptually difficult to grasp and have never (or are
> rarely) been thought about before? The process of writing drawing pictures,
> writing down equations and muttering is the best you can do to try and
> communicate what you want to.
I can't comment on the physical examples. But maybe I can make it
clearer what triggered my response. When I was attending maths courses
at university I all the time had the impression that I wasn't really
_tought_ maths -- rather the profs demonstrated a whole lot of proofs,
but they didn't explain how and why they chose the next step. I'm quite
sure that there are heuristics and, yes, patterns involved, but I
haven't been told about them. Instead, I felt that I had to rediscover
everything on my own because the knowledge about actually practising
maths was hardly if at all formalized. I may be doing mathematicians
wrong, but it was my impression nevertheless. And that's what I carried
over to physics in my previous posting.
Interestingly, things are different regarding software. We have computer
science that deals among other things with properties of programs. And
we have an aspiring engineering disciplin that deals with the practice
of developing -- "doing" -- software. In my opinion, patterns as
currently understood belong in the later.
Michael Schuerig
> schu...@acm.org (Michael Schuerig) writes:
[programmer deprived of using multi-methods]
> But then they start reading the patterns literature and discover that
> it's actually the visitor pattern.
>
> My view is that they ought to feel a bit happier about what they've
> been doing at that point, because the seeming kludge is actually
> thought to be a reasonably good way of doing things.
>
> But then they talk with Michael Schuerig who says some things they
> find confusing. For instance: "A pattern is definitely *not* what the
> experts *do*." That makes it sound like the experts might have some
> better ways of doing things, ways that are, for some reason, not
> patterns. Though M.S. also says that experts use patterns, it
> sounds like this is not an at all straightforward thing and that
> one ought to be very cautious about this technique that turned out
> to be the visitor pattern.
No. Can we put this to rest? That experts do something is neither a
necessary nor a sufficient condition for it to be a pattern. And that's
all I was trying to say.
> > > Humm. A lot of patterns seem of similar generality to me.
> >
> > Then just rename then internally to idioms and, if necessary, keep outer
> > appearance up.
>
> Why would I want to rename them? I have no objection to calling them
> patterns, or to thinking of them as patterns.
Well, then you may have to accept that other people divide your class of
patterns still further.
> (BTW, where Gabriel has complained that the Gang of Four book has
> too narrow a notion of patterns, you seem to think its notion is
> too broad, that it includes things that are not patterns at all,
> but instead idioms. For whatever reason, I find Gabriel's view
> much easier to understand.)
Actually, I agree with Gabriel. The GOF-book is very narrowly tied to
pretty low-level patterns, that in some cases are below my pattern
threshold. This doesn't make it a bad book in any way, of course. But it
set an unfortunate precedent as this thread is constantly showing. The
patterns in that book aren't paradigmatic patterns, but they're often
seen that way.
It would be interesting to hear what exactly happened at the GOF show
trial at this year's OOPSLA.
Robert Monfera
Michael Schuerig wrote:
> When I was attending maths courses
> at university I all the time had the impression that I wasn't really
> _tought_ maths -- rather the profs demonstrated a whole lot of proofs,
> but they didn't explain how and why they chose the next step. I'm quite
> sure that there are heuristics and, yes, patterns involved, but I
> haven't been told about them. Instead, I felt that I had to rediscover
> everything on my own [...]
This is good. Often the methods of theaching is indirect. I am sure
those patterns have eventually _developed_ in you - so the education has
reached its goals.
Another feature of teaching is that it is paved with lies - e.g., you
won't often go to relativity theory before learning Newtonian physics.
Some cognitive science books help understand the underlying reasons. My
favorite writer, Laszlo Mero et al wrote this: "Ways of Thinking : The
Limits of Rational Thought and Artificial Intelligence", 1990, ISBN:
9810202660.
<IDIOT FORMATTING ON>
How about these patterns: IndirectTeaching, TeachingByExample,
TeachingByLying, or these antipatterns: LearnSexFromBooks,
FormalizeMathematics?
Regards
RobertMonfera
<IDIOT FORMATTING OFF>
Pierre R. Mai
> > BTW, what do you think of "Value + Quantity"? There you don't carry
> > around plain values, but their units as well. It's some kind of
> > home-made manifest typing. I'd be surprised if something like this is
> > not used in the Lisp community.
>
> Probably. I think there was a version of Scheme used for something
> related to (I think) SGML that had values with units.
The language you're probably thinking of is DSSSL, the ISO standard
SGML transformation and "style-sheet" language. It includes an
expression language that is heavily based on Scheme with a number of
differences and extensions, including support for keyword arguments
(keywords are written with a trailing : though) and unit-based
values...
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Antonio Leitao
Michael> Antonio Leitao <a...@gia.ist.utl.pt> wrote:
>> As an example, I developped high-order functions to deal with sets in
>> Common Lisp. I had mappings, foldings, filters, etc. Although most
>> of the time I was using these functions in combination, such as
>> folding after mapping after filtering, I usually prefered to leave the
>> combination explicit than to write a super-powerful
>> fold-after-map-after-filter that accepts several arguments and does
>> everything at the same time at warp speed.
Michael> I'm curious, is fold-after-map-after-filter really a useful,
Michael> "understandable" abstraction?
If you count the number of times it occurred in the code you would
think it is useful. But I prefer to see the composition explicit.
As an example, we can compute the sum of the squares of the odd
numbers in a list. That's a fold after a map after a filter.
There's a similar (but smaller) pattern in Common Lisp's reduce. It
includes the :key argument that hides (and optimizes) a map, i.e.,
(reduce #'+ '(1 2 3 4) :key #'square) <=>
(reduce #'+ (mapcar #'square+ '(1 2 3 4)))
Although it's just a fold after a map, if performance was not a
concern, I would prefer to see the second version.
Antonio.
William Deakin
> When I was attending maths courses ...[I]... had the impression that I wasn't
> really _tought_ maths -- rather the profs demonstrated a whole lot of proofs,
> but they didn't explain how and why they chose the next step.
In my experience, physics is a bit different from this. Often you cannot `explain
how and why' you choose a next step. You have a tool kit of `patterns' that you
try, having leant them through an apprenticeship. You pick the one that `works',
that is, answers what you want answering or explains what is observed and
predicts some other stuff you can go out and look for. You also try find the most
`elegant' model. A lot of very good theoretical physicists talk about having a
nose for an answer.
Then again maybe this is an explaination choosing the next step. But it is the
same answer you give a toddler who has discovered the questions "why". That is,
small child says `why?' and you say `because' (ad nauseum). In Italian I
understand this is something like "perchè?" "perchè!" ;)
I should also add, I spent some years failing a research degree, and this is a
different kettle of fish from being taught physics. And that this colours my
world-view.
> I'm quite sure that there are heuristics and, yes, patterns involved, but I
> haven't been told about them.
OK then. I remember taking `problem solving' classes. You had an hour and had to
answer questions like `if Birmingham was levelled to the ground in a massive
disaster, how deep is the pile of bricks?' or `there is a large fountain in the
centre of Geneva, how high can it reach?' This is very frustrating. But by trying
to answer the questions and then working through answers with the class, you
learn `patterns' of problem solving. Eventually. Although I cannot sit down and
tell you about these patterns , it is something that can be taught given time.
> ...I felt that I had to rediscover everything on my own because the knowledge
> about actually practising maths was hardly if at all formalized ... And that's
> what I carried over to physics in my previous posting.
Physics is (well, can be) a different type of fish. I was also taught a bit of
maths but it sounds like it was from a different (more pragmatic?) angle. For
example: Here is a Bessel function it has these properties (followed by a a bit
of hand waving). It is useful when calculating the resonant frequencies of a
kettle drum. Now lets look at Fourier transforms because next week in the lab you
will work out the characteristics of a loudspeaker. &c
> Interestingly, things are different regarding software. We have computer
> science that deals among other things with properties of programs. And we have
> an aspiring engineering disciplin...
I think that although CS is an aspiring engineering discipline it has a long way
to go. For example: People have built bridges for hundreds (thousands?) of years
but have only written computer programs for 40-60 years. And until programmers
have extensive history and experience of making mistakes, and people are taught
about these mistakes, and about quality control and all the other dull stuff
engineers have to learn (my brother trained as a mechanical engineer), computing
will be a creative art and should never pretend to have anything to do with
engineering.
I think it was Niels Bohr (or Ernest Rutherford) who said something about an
expert being a man who has made every mistake it is possible to make in a narrow
field. Although I should now question why I mention this here ;)
> ...that deals with the practice of developing -- "doing" -- software. In my
> opinion, patterns as currently understood belong in the later.
I agree but then again I am a pragmatist. Maybe it's the effect of living in
Yorkshire next ot the North sea ;).
Yes, there is a difference between maths teaching and software development.
However, I am less certain about the differences between this and maths research.
Any problem solving or research activities encompasses similar techniques, and
these techiniques can (should?) be called patterns.
Best Regards,
:) will
William Deakin
> Another feature of teaching is that it is paved with lies
Are these lies? or are they simplifications and approximations? Unless you
are travelling at about 0.5c it is very difficult to tell the difference
between Newtonian (or is that Gallilean?) mechanics and relativistic
mechanics.
Thanks for the reference.
Best Regards,
:) will
ps: what about the DoAsISayButNotAsIDo pattern? ;)
Michael Schuerig
> Michael Schuerig wrote:
[Maths teaching]
> > I'm quite sure that there are heuristics and, yes, patterns involved, but I
> > haven't been told about them.
>
> OK then. I remember taking `problem solving' classes. You had an hour and
> had to answer questions like `if Birmingham was levelled to the ground in
> a massive disaster, how deep is the pile of bricks?' or `there is a large
> fountain in the centre of Geneva, how high can it reach?' This is very
> frustrating. But by trying to answer the questions and then working
> through answers with the class, you learn `patterns' of problem solving.
> Eventually. Although I cannot sit down and tell you about these patterns ,
> it is something that can be taught given time.
But apparently these patterns can't be made explicit, or at least aren't
yet. There has been research into general problem solving, of course,
and in particular some interesting research that discovered some of our
"Antipatterns" of problem solvind, e.g., Kahneman/Slovic/Tversky's
"Judgment under Uncertainty: Heuristics and Biases" (Cambridge UP,
1982). A difference is that patterns as discussed in the software field,
are domain specific.
> > Interestingly, things are different regarding software. We have computer
> > science that deals among other things with properties of programs. And
> > we have an aspiring engineering disciplin...
>
> I think that although CS is an aspiring engineering discipline it has a
> long way to go.
That's what makes it "aspiring"...
> Yes, there is a difference between maths teaching and software
> development. However, I am less certain about the differences between this
> and maths research. Any problem solving or research activities encompasses
> similar techniques, and these techiniques can (should?) be called
> patterns.
And it would be nice if the people involved made those patterns
explicit.
hrum...@cc.hut.fi
> But apparently these patterns can't be made explicit, or at least aren't
> yet. There has been research into general problem solving, of course,
> and in particular some interesting research that discovered some of our
> "Antipatterns" of problem solvind, e.g., Kahneman/Slovic/Tversky's
> "Judgment under Uncertainty: Heuristics and Biases" (Cambridge UP,
> 1982). A difference is that patterns as discussed in the software field,
> are domain specific.
I understand there's active research on the subject of mathematical
problem solving, for the purpose of improving the education of
mathematics. It seems to me however, that the level of strategies the
problem solving research is concerned with, even if specialized to
particular classes of mathematical problems, is more abstract and higher
level than what goes for patterns in software engineering.
In the way that software patterns describe solutions to specific kinds
of development problems, they resemble mathematical theorems or better
yet, explicit methods of solving specific kinds of problems, like the
finite element method: you have a solution to a particular class of
recurring problems, applicable under specified conditions, and the
result may or may not be what you want.
For the record, I have only a passing familiarity with either software
patterns or the study of mathematical problem solving, but that never
stopped anyone on Usenet did it?
Hannu Rummukainen
Weiqi Gao
I've been following this thread with interest. I've also been reading
Richard Gabriel's book recently (and I've read the GoF book several
times through). And would like to offer some of my opinions for others
to take apart.
1. The self claimed knowledgable uses "patterns" to communicate what
works, but unexplainable, to the general public. Had their methods been
substantiatable using the scientific method, they would be communicated
as theorems. Fermat's Last Theorem was a "pattern" for three hundred
years before finally proven.
2. In all fields except mathematics and logic, people tend to readily
accept these "patterns" and be satisfied with their practical
applicability. For the practical person, the lack of rigor is not a
detriment. And indeed the use of these "patterns" yield "good enough"
results. Newton's Laws are such patterns. But the elaborate rules used
by astronomists to calculate the abberations in the planets circular
motion around the earth could also be classified as "patterns", and
yeilded accurate results.
3. The lack of rigor of "patterns" dictates that they should evolve.
Internal evolution improves the existing pattern and make it apply to
new circumstances or apply to existing circumstances better. The
singleton pattern, as described in GoF, does not work in a
multi-threaded program. An "improved" Singleton pattern exists to deal
with this situation.
4. The lack of rigor can also originate from the starting assumptions
being inadaquate, in which case new hypotheses are formulated and the
existing pattern is overthrown. Witness the heliocentric movement
(religous ramifications aside). The "come to the city square and chat"
pattern was replaced by the "subscribe to the newspaper" pattern was
replaced by the "watch the television" pattern was replaced by the
"register to receive email alert and win big prize" pattern (the
"updatable encyclopedia chip brain implant" pattern awaits).
5. "Pattern"'s goal in life is to please humans, both the originator of
the "pattern", who contend himself in the knowledge that his
incomprehensible balling has a popular name, and the followers, whose
problems were readily "solved" by such patterns. Imagine the days prior
to the invention of the quadratic formula, and the only way to solve a
quadratic equation is by factoring. The earth must had been populated
by "factorization methodologists" who talks about "patterns" of
factorizing quadratic equations.
6. The true scientists work to make the "patterns" rigorous! By doing
so pull them from high glory down to earth, and eventually make them
unnoticable. The "for loop" must have been a pattern long ago. "Tail
recursion" another. They have graduated from the ranks of patterns
because they are in certain sense "done"---They've gotten NAMES.
--
Weiqi Gao
weiq...@a.crl.com
Michael Schuerig
> 1. The self claimed knowledgable uses "patterns" to communicate what
> works, but unexplainable, to the general public. Had their methods been
> substantiatable using the scientific method, they would be communicated
> as theorems. Fermat's Last Theorem was a "pattern" for three hundred
> years before finally proven.
No, a pattern is not at all a contender for theoremhood. A pattern sole
justification in life is that there is no and probably cannot(!) be an
applicable, hard and fast theorem. A theorem tells you the answer, a
patterns tells you what to consider and leaves it up to your judgment
what to do.
Weiqi Gao
>
> Weiqi Gao <weiq...@a.crl.com> wrote:
>
> > 1. The self claimed knowledgable uses "patterns" to communicate what
> > works, but unexplainable, to the general public. Had their methods been
> > substantiatable using the scientific method, they would be communicated
> > as theorems. Fermat's Last Theorem was a "pattern" for three hundred
> > years before finally proven.
>
> No, a pattern is not at all a contender for theoremhood. A pattern sole
> justification in life is that there is no and probably cannot(!) be an
> applicable, hard and fast theorem. A theorem tells you the answer, a
> patterns tells you what to consider and leaves it up to your judgment
> what to do.
The fundamental doubt I have for patterns is this: If Big Shot Mohoney
tells everybody the "Combobox" pattern (imagine your self in a
pre-combobox era) is an appropriate solution to such-and-such problem in
such-and-such situation, how do I know if his teaching is GOOD?
Granted, he's a lot more experienced than everyone else, but a lot of
experienced people had been wrong before. Not because of their lack of
intellect, but perhaps because they lacked the tools and the cumulative
human knowledge needed. Again the geocentrists (and more recently the
pre-Goedel Hilbertische mathematical logic program).
I haven't mentioned the opportunists who knowingly propogate teachings
that they themselves know were wrong for mere personal gains.
In other words, where do I derive my judgement from?
--
Weiqi Gao
weiq...@a.crl.com
Stig Hemmer
> The fundamental doubt I have for patterns is this: If Big Shot Mohoney
> tells everybody the "Combobox" pattern (imagine your self in a
> pre-combobox era) is an appropriate solution to such-and-such problem in
> such-and-such situation, how do I know if his teaching is GOOD?
You try it out and see if it works.
Stig Hemmer,
Jack of a Few Trades.
Aaron Gross
> For me, abstractions are extremely usefull, but as the number of
> abstractions grows it becomes harder and harder to remember all of
> them. Sometimes, it's preferable to have just a dozen of easily
> understood and combinable abstractions than to have undreds of them
> very hard to remember. As long as I can write simple combinations
> of these abstractions, I do not jump into defining more and more
> abstractions.
You don't have to remember all the functions and macros. Back to
Gabriel's concrete example: If you want to find the first mis-match in
two sequences, you might pause for a moment and reflect that this
seems like a basic, commonly-arising task involving sequences. Hence,
there's a fair chance that there already exists such a function in
Common Lisp. You can then search for it. After you've found it the
first time, you know it's there.
Remember that Gabriel's objection was that the use of MISMATCH was
actually harder to read (for someone unfamiliar with the function)
than the corresponding nine-line pattern. I think that's ridiculous.
Erik Naggum
| Remember that Gabriel's objection was that the use of MISMATCH was
| actually harder to read (for someone unfamiliar with the function) than
| the corresponding nine-line pattern. I think that's ridiculous.
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.
#:Erik
Tim Bradshaw
> I wouldn't consider the first version "extremely inefficient". In
> fact, the mapcar should be dominant and the difference should be
> minimal. A small experience shows us that the results are quite the
> opposite of the expected.
> [...]
(with-cynicism
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.
)
--tim
Michael Schuerig
[snip]
> 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.
[snip]
> 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.
I disagree with your premise. You can't cut and paste patterns. Even
though in "typical" languages such as C++ and Java it is common that
their _implementations_ can be cut and pasted. So, in these languages
patterns are there for wont of a better abstraction.
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).
Erik Naggum
| I disagree with your premise. You can't cut and paste patterns.
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.
#:Erik
Erik Naggum
| A curse on the programmer who first picked up a Christopher Alexander
| book! Great for buildings, horrible for software.
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.
#:Erik
Michael Schuerig
> * Michael Schuerig
> | I disagree with your premise. You can't cut and paste patterns.
>
> 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.
Okay. I agree with the first part, I don't agree with the second.
Patterns *taken seriously* don't facilitate cut-and-paste programming.
Although this may happen, if they're not taken seriously and used just
for the hype ("Now paste some Factory here...").
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).
> | 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.
Let's see if I can sort out how we approach this. In my opinion, the
extra bit of abstractions that patterns provide is well worth it,
because it actually lifts the level of abstraction most software
developers can cope with (at least the ones I usually meet in real life
-- a very different place from usenet). For this benefit I tend to
accept the detrimental effect of "canned abstractions" that keep people
from growing their own abstractions. Now, if I understand you correctly,
it's exactly this effect that you deplore.
> 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.
So we seem to agree.
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.
William Deakin
> Will wrote:
>
> But apparently these patterns can't be made explicit, or at least aren't yet.
What do you mean by explicit? Is this not explicit because I can't tell you over
usenet? Or because I would ask you to take a course of training involving
discussion, reflection and and practice?
> > > Interestingly, things are different regarding software. We have computer
> > > science that deals among other things with properties of programs. And
> > > we have an aspiring engineering disciplin...
> >
> > I think that although CS is an aspiring engineering discipline it has a
> > long way to go.
>
> That's what makes it "aspiring"...
When does aspiring become actual? At the present rates of progress I would expect
CS to mature into an engineering discipline some time around 2249... ;)
> > Yes, there is a difference between maths teaching and software
> > development. However, I am less certain about the differences between this
> > and maths research. Any problem solving or research activities encompasses
> > similar techniques, and these techiniques can (should?) be called
> > patterns.
>
> And it would be nice if the people involved made those patterns explicit.
Yes it would. But this is not be possible.
<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,
:) will
Jeff Dalton
> Tim Bradshaw <t...@tfeb.org> wrote:
> > But now there's a problem. If you can formalise the description of
> > some proposed `pattern', then you can invent a language which talks
> > about it directly -- because programming languages really just *are*
> > formal descriptions of things. And of course Lisp is the language
> > you'd do that in because Lisp is kind of about this metalinguistic
> > stuff in some sense.
>
> Here you are more or less talking about idioms.
Why? What's the problem? You take something that's regarded
as a pattern and provide direct suppport for in a language.
How does it end up being an idiom? Or is the idea that you
cannot provide such direct support for patterns but only for
things that weren't really patterns in the first place?
> > But if you can have it directly in some language then it isn't a
> > pattern (they say).
>
> You can't really have a pattern directly in the language. The language
> itself does not tell you when to use whatever cool feature it
> provides. A pattern describing its application can. It's just that the
> implementation of some of those patterns is ridiculously easy in some
> languages.
Well, I think it's reasonably clear what Tim has in mind, and hence
to understand the idea of having a pattern directly in the language.
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.
But that would just be a translation of what Tim was saying into
official pattern-speak (we might call it), rather than a disagreement
with what he was saying.
William Deakin
> But that would just be a translation...into official pattern-speak...
Could this be a new of form of double-think?
Orwellian-ly yours,
:) will
William Deakin
hrum...@cc.hut.fi wrote:
> For the record, I have only a passing familiarity with either software
> patterns or the study of mathematical problem solving, but that never
> stopped anyone on Usenet did it?
I agree. I find complete knowing something about what you are talking about is
a major hinderance to heated debate ;)
Best Regards,
:) will
Jeff Dalton
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>
> > schu...@acm.org (Michael Schuerig) writes:
>
> [programmer deprived of using multi-methods]
> > But then they start reading the patterns literature and discover that
> > it's actually the visitor pattern.
> >
> > My view is that they ought to feel a bit happier about what they've
> > been doing at that point, because the seeming kludge is actually
> > thought to be a reasonably good way of doing things.
The problem I have with this discussion is that my point was basically
what's in the paragraph just above, and your claim about experts was
posted as if it somehow showed I was wrong. And your remark does
*seem* to be a disageement.
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.
> > > > Humm. A lot of patterns seem of similar generality to me.
> > >
> > > Then just rename then internally to idioms and, if necessary, keep outer
> > > appearance up.
> >
> > Why would I want to rename them? I have no objection to calling them
> > patterns, or to thinking of them as patterns.
>
> Well, then you may have to accept that other people divide your class of
> patterns still further.
But there will always be subkinds of patterns, in any case.
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.
> > (BTW, where Gabriel has complained that the Gang of Four book has
> > too narrow a notion of patterns, you seem to think its notion is
> > too broad, that it includes things that are not patterns at all,
> > but instead idioms. For whatever reason, I find Gabriel's view
> > much easier to understand.)
>
> Actually, I agree with Gabriel. The GOF-book is very narrowly tied to
> pretty low-level patterns, that in some cases are below my pattern
> threshold. This doesn't make it a bad book in any way, of course. But it
> set an unfortunate precedent as this thread is constantly showing. The
> patterns in that book aren't paradigmatic patterns, but they're often
> seen that way.
Ther question here has been whether the patterns in the book are
patterns at all, not whether they're paradigmatic.
> It would be interesting to hear what exactly happened at the GOF show
> trial at this year's OOPSLA.
Yes.
-- jd
Jeff Dalton
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> writes:
> > > BTW, what do you think of "Value + Quantity"? There you don't carry
> > > around plain values, but their units as well. It's some kind of
> > > home-made manifest typing. I'd be surprised if something like this is
> > > not used in the Lisp community.
> > Probably. I think there was a version of Scheme used for something
> > related to (I think) SGML that had values with units.
> The language you're probably thinking of is DSSSL, the ISO standard
> SGML transformation and "style-sheet" language.
Yes, that's it. Thanks.
-- jeff
Michael Schuerig
> Michael Schuerig wrote:
> > But apparently these patterns can't be made explicit, or at least aren't
> > yet.
>
> What do you mean by explicit? Is this not explicit because I can't tell
> you over usenet? Or because I would ask you to take a course of training
> involving discussion, reflection and and practice?
Yes to all. We may agree that the patterns are there, but apparently we
can't make them explicit and have to convey them by a different means
(every Wittgensteinian would hit me with the Private Language Argument
now...).
> > > I think that although CS is an aspiring engineering discipline it has a
> > > long way to go.
> >
> > That's what makes it "aspiring"...
>
> When does aspiring become actual? At the present rates of progress I would
> expect CS to mature into an engineering discipline some time around
> 2249... ;)
Well, others have taken longer.
> > > Yes, there is a difference between maths teaching and software
> > > development. However, I am less certain about the differences between this
> > > and maths research. Any problem solving or research activities encompasses
> > > similar techniques, and these techiniques can (should?) be called
> > > patterns.
> >
> > And it would be nice if the people involved made those patterns explicit.
>
> Yes it would. But this is not be possible.
Is there some in-principle reason for this?
> <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>
In the preface to the TLP, Wittgenstein himself writes
<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 Schuerig
> 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.
Yes.
Michael Schuerig
> schu...@acm.org (Michael Schuerig) writes:
> Well, I think it's reasonably clear what Tim has in mind, and hence
> to understand the idea of having a pattern directly in the language.
The most important thing about a pattern is that it gives you guidance
when to apply it. A language feature does not do that.
> 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.
The apparatus for subroutine call itself is not a pattern. The reasoning
that goes into deciding when and where to use it may well have been
patternized.
> 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.
Sorry, I don't consider this a debating club or something akin. I don't
need a way out. I don't need to convince you or anyone. I'm fully
content when I succeed in _explaining_ my position to the other
discussants. And most of all I don't need adversarial arguments.
Michael
slightly touchy
root
| The most important thing about a pattern is that it gives you guidance
| when to apply it. A language feature does not do that.
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.
#:Erik
Michael Schuerig
> * Michael Schuerig
> | The most important thing about a pattern is that it gives you guidance
> | when to apply it. A language feature does not do that.
>
> 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.
I have never explicitly refused to acknowledge that good programming
practice can exist without patterns. If you think I did, please show me
a case. Or just take my word that I'd be sorry to have done so in case I
ever did -- which I doubt.
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.
> 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.
Then the people "here" seem to have put up a strawman.
> 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.
But we don't do this. Usually, in this group patterns aren't mentioned
at all. There are other groups (not just on usenet), where patterns are
very prominent. So what. I take discussing patterns to be worthwhile,
even though I'm not particularly interested in some esoteric connections
to zen buddhism or whatever. Of course there are other worthwhile topics
for discussion -- but in my opinion it's more prudent to say that they
have too little mindshare rather than that patterns have too much. Put
to the point: I'm interested in patterns to exactly the extend that they
help me write better software. Most of all, I'm thankful that the whole
pattern movement has given me a chance to peek at the hard-won insights
of other people.
Michael
Eugene Wallingford
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.
--
+-------------------------------------------------------------------------+
| Eugene Wallingford wall...@cs.uni.edu |
| University of Northern Iowa |
| Department of Computer Science |
+-------------------------------------------------------------------------+
--
+-------------------------------------------------------------------------+
| Eugene Wallingford wall...@cs.uni.edu |
| University of Northern Iowa |
| Intelligent Systems Laboratory |
+-------------------------------------------------------------------------+
--
+-------------------------------------------------------------------------+
| Eugene Wallingford wall...@cs.uni.edu |
| University of Northern Iowa |
| Intelligent Systems Laboratory |
+-------------------------------------------------------------------------+
Frank A. Adrian
Eugene Wallingford <wall...@cs.uni.edu> wrote in message
news:81ust8$k...@news.uni.edu...
> I don't see how
> Alexander's idea can be great for buildings and yet horrible
> for software.
I is horrible because software is NOT a building. Software architecture is
NOT the same thing as building architecture. It is like saying that
debugging is the same as pest extermination. Analogies are good. Knowing
their limits is 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.
faa
William Deakin
> Will wrote:
> > What do you mean by explicit? Is this not explicit because I can't tell
> > you over usenet? Or because I would ask you to take a course of training
> > involving discussion, reflection and and practice?
> Yes to all. We may agree that the patterns are there, but apparently we can't make
> them explicit and have to convey them by a different means
OK then. I would say there are lots of patterns that can be made explicit. But there
are some in particular, to do with problem solving (say), that involve learning a
process through doing and that cannot be made explicit.
<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.
> (every Wittgensteinian would hit me with the Private Language Argument now...).
Now would I do such a thing? Don't you think Wittgenstein had a point tho' ;)
Anyway, I suppose I am asking for you to be explicit in your meaning of explicit.
This is because I am not sure that we are using the word in the same way. A language
game perhaps? ;)
> > > ...it would be nice if the people involved made those patterns explicit.
> > Yes it would. But this is not be possible.
> Is there some in-principle reason for this?
I think there is. Yes. Written and spoken language is not (necessarily) up to the
job of communicating these things. It is then down to other methods to try and
communicate this kind of information.
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.
> In the preface to the TLP, Wittgenstein himself writes
>
> <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>
Thanks for the quote. I think it sums up some of the problems I see with the
Tractatus :)
> What you're saying in your previous paragraphs and postings is much
> closer to the views Wittgenstein espouses in his Philosophical
> Investigations.
Well, I must compliment you on your perception. Of Wittgenstein's works, I like, if
that is the right word, maybe this should be `am influenced' or `am interested in',
Philosophical Investigations the most. This is why I own a copy of PI and not the
Tratatus. I struggled through bits of Tractatus some years ago and gave it away but
read and re-read Philosophical Investigations.
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,
:) will
Jeff Dalton
> Let's see if I can sort out how we approach this. In my opinion, the
> extra bit of abstractions that patterns provide is well worth it,
A problem with regarding patterns (used in code) as providing
abstraction is that when reading the code you have to determine that
it is in fact an instance of the pattern. That someone has
*documented* it as such is not enough, because the doc may be
out of date or just plain wrong. This is especially difficult
when the pattern involves code in separate classes, files, or
whatever.
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.
> > | 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!
That's an interesting claim, and I'm sure there's at least some truth
to it; but I wonder what the evidence is. Most of the time? How do
you know? I can think of a number of cases when patterns were
identified, and even talked about using the word "pattern", before
the official pattern movement even existed.
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.
> because it actually lifts the level of abstraction most software
> developers can cope with (at least the ones I usually meet in real life
> -- a very different place from usenet). For this benefit I tend to
> accept the detrimental effect of "canned abstractions" that keep people
> from growing their own abstractions.
"Canned" abstractions do not prevent people form growing their own.
They provide higher-level constructs that make it easier for people
to develop even higher-level abstractions, and they provide valuable
examples.
-- j
Jeff Dalton
> Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>
> > schu...@acm.org (Michael Schuerig) writes:
>
> > Well, I think it's reasonably clear what Tim has in mind, and hence
> > to understand the idea of having a pattern directly in the language.
>
> The most important thing about a pattern is that it gives you guidance
> when to apply it. A language feature does not do that.
Sure, though it's not quite completely true. There's always some
implicit guidance in the argument types or the syntax or whatever.
In any case, even without that, it is reasonably clear what Tim has
in mind, etc.
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.
> > 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.
> The apparatus for subroutine call itself is not a pattern. The reasoning
> that goes into deciding when and where to use it may well have been
> patternized.
> > 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.
> Sorry, I don't consider this a debating club or something akin. I don't
> need a way out. I don't need to convince you or anyone. I'm fully
> content when I succeed in _explaining_ my position to the other
> discussants. And most of all I don't need adversarial arguments.
You're right that we shouldn't treat the newsgroup as a debating club.
On the net, it's easy to fall into adversarial ways of doing things.
At least I find it so. Anyway, I don't intend any hostility to you
personally.
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.
-- j
Michael Schuerig
> Michael Schuerig wrote:
> <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>
(Once upon a time I found an english translation at
<http://www.bookstore.uidaho.edu/Philosophy/>)
<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>
> > (every Wittgensteinian would hit me with the Private Language Argument
> > now...).
>
> Now would I do such a thing? Don't you think Wittgenstein had a point tho' ;)
Yes, of course he has a point. And when I wear my philosopher hat I do
accept the Private Language Argument (or rather the argument saying
there can't be such a thing).
> 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) ;)
:-) Well, if I had not inadvertantly drifted into professional software
development I really ought to be working on my master's thesis in
philosophy. But programming is so much easier. No, actually it's not
easier on the whole, but at least for me it's a lot easier to see what
the next step is.
Best regards,