Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!ram From: ram@spice.cs.cmu.edu.UUCP Newsgroups: comp.lang.lisp Subject: Re: Against the Tide of Common LISP Message-ID: <1131@spice.cs.cmu.edu> Date: Wed, 11-Feb-87 06:41:44 EST Article-I.D.: spice.1131 Posted: Wed Feb 11 06:41:44 1987 Date-Received: Thu, 12-Feb-87 04:25:47 EST References: <2545@well.UUCP> Organization: Carnegie-Mellon University, CS/RI Lines: 213 Keywords: Flame Repeat Original Common LISP Tide For the record, I am not replying to this message in hopes of convincing MR. Jacobs of anything, since he has shown himself to be beyond reason in previous discussions. I simply want to point out that almost nothing he says is true, and the few true things he says are irrelevant. > >I think CL is the WORST thing that could possibly happen to LISP. In fact, I >consider it a language different from "true" LISP. CL has everything in the >world in it, usually in 3 different forms and 4 different flavors, with 6 >different options. I think the only thing they left out was FEXPRs... I presume that you have some dialect in mind which is "true" lisp, but all the Lisps I have every used have had a great deal of duplication of functionality, since Lisps tend to accrete rather than being designed. > >It is obviously intended to be a "compileable" language, not an interpreted >language. By nature it will be very slow; somebody would have to spend quite > a bit of time and $ to make a "fast" interpreted version (say for a VAX). Compiled = slow? How silly of me, I thought the purpose of compilation was to make code run faster. I presume that there is an unspoken assumption that you will run code interpreted even though a compiler is available. In my experience, non-stupid people debug code compiled when they have a modern Lisp environment supporting incremental compilation. >The grotesque complexity and plethora of data types presents incredible >problems to the developer; it was several years before Golden Hill had >lexical scoping, and NIL from MIT DOES NOT HAVE A GARBAGE COLLECTOR!!!! It is true that Common Lisp has a few types that are non-trivial to implement and are not supported by some Lisps. The main examples are bignum, complex and ratio arithmetic. Your other two assertions, while true, have nothing to do with the complexity of Common Lisp datatypes. It is true that implementing full lexical scoping in a compiler is non-trivial, causing some implementors headaches; the Common Lisp designers felt that this cost was adequately compensated for by the increment in power and cleanliness. NIL existed after a fashion before anyone had thought of designing Common Lisp, and it didn't have a garbage collector then either. >Further, there are inconsistencies and flat out errors in the book. So many >things are left vague, poorly defined and "to the developer". True: this is a major motivation for the current ANSI standards effort. However, some of the vaguenesses in the spec are quite deliberate. People who have not participated in a standards effort invloving many implementations may not appreciate how much a standard can be simplified my leaving behavior in obscure cases undefined. This is quite different from documenting a single implementation system where you can assume that what the implementation does is the "right" thing. > >The entire INTERLISP arena is left out of the range of compatability. True, and quite deliberate. Interlisp is substantially incompatible with all the Lisps that we wanted to be compatible with. Of course, this is largely because all of the active members of the Common Lisp design effort were using Maclisp family Lisps. Other Lisp communities such as XEROX/Interlisp were hiding their heads in the sand, hoping we would never accomplish anything. > >As a last shot; most of the fancy Expert Systems (KEE, ART) are implemented in >Common LISP. Once again we hear that LISP is "too slow" for such things, when >a large part of it is the use of Common LISP as opposed to a "faster" form >(i.e. such as with shallow dynamic binding and simpler LAMBDA variables; they >should have left the &aux, etc as macros). Every operation in CL is very >expensive in terms of CPU... Even if you personally insist on using an interpreter, vendors using Lisp as an implementation substrate will be less stupid. As you mentioned earlier, Common Lisp was designed to be efficiently compilable, and none of the above "ineffencies" have a negative effect on compiled code. As for fundamental innefficiency, look at Robert P. Gabriel's book on measuring Lisp performance. He compares many Lisps, both Common and uncommon, and the Common Lisps do quite well. For example, Lucid Common Lisp on the SUN is 2x-4x faster than Franz on the same hardware. > >______________________________________________________________ > >I forgot to leave out the fact that I do NOT like lexical scoping in LISP; to >allow both dynamic and lexical makes the performance even worse. Only in compiled code... >To me, >lexical scoping was and should be a compiler OPTIMIZATION, not an inherent >part of the language semantics. Sticking your foot in your mouth and revealing that you have no understanding of lexical scoping (as opposed to local scoping)... >I can accept SCHEME, where you always know >that it's lexical, but CL could drive you crazy (especially if you were >testing/debugging other people's code). For one, Common Lisp is hardly unique in having both dynamic and static variables. Every Lisp that I know of allows dynamic binding, and every Lisp that I know of will use also statically bind variables, at least in compiled code. I believe that Scheme allows fluid binding; certainly T does. I have also never heard anyone but you claim that mixed lexical/dynamic scoping makes programs hard to understand, and I have to deal with some real dimbulb users as part of my job. In contrast, I have frequently heard claimed (and personally experienced) obscure bugs and interactions due to the use of dynamic scoping. > >BTW, I think the book is poorly written and assume a great deal of knowledge >about LISP and MACLISP in particular. I wouldn't give it to ANYBODY to learn >LISP > >...Not only does he assume you know a lot about LISP, he assume you know a LOT >about half the other existing implementations to boot. There is a substantial element of truth here, but then CLTL wasn't intended to be a "learning programming through Lisp book". The problem is that you have all these Lisp wizards defining a standard, and they find it impossible to "think like a novice" when specifying things. > >I am inclined to doubt that it is possible to write a good introductory text on >Common LISP; This is questionable. I believe that all the Maclisp family Lisp introductory books are going over to Common Lisp (e.g. Winston and Horne). Of course, you probably consider these books to be a priori not good. >you d**n near need to understand ALL of it before you can start >to use it. There is nowhere near the basic underlying set of primitives (or >philosophy) to start with, as there is in Real LISP (RL vs CL). Not really true, although this is the closest that you have come to a valid esthetic argument against Common Lisp. Once you understand it, you realize that there actually is a primitive subset, but this is only hinted at in CLTL. >You'll notice >that there is almost NO defining of functions using LISP in the Steele book. >Yet one of the best things about Real LISP is the precise definition of a >function! Once again, this is largely a result of good standards practice. If you say that a given operation is equivalent to a piece of code, then you vastly over-specify the operation, since you require that the result be the same for *all possible conditions*. This unnecessarily restricts the implementation, resulting the the performance penalties you so dread. > >Even when using Common LISP (NIL), I deliberately use a subset. I'm always >amazed when I pick up the book; I always find something that makes me curse. I will avoid elaborating possible conclusions about your limited mental capacity; this statement only shows how emotionally involved you are in denouncing a system which takes you out of your depth. >Friday I was in a bookstore and saw a new LISP book ("Looking at LISP", I >think, the author's name escapes me). The author uses SETF instead of SETQ, >stating that SETF will eventually replace SETQ and SET (!!). Thinking that >this was an error, I checked in Steel; lo and behold, tis true (sort of). >In 2 2/3 pages devoted to SETF, there is >> 1 << line at the very bottom >of page 94! And it isn't even clear; if the variable is lexically bound AND >dynamically bound, which gets changed (or is it BOTH)? Who knows? >Where is the definitive reference? Well, obviously it sets the place named, and in a particular lexical environment, a given name only names one variable, lexical or special as the case may be. Your incomprehension provides some evidence that the specification is inadequate, although you do exhibit an amazing capacity for incomprehension. > >"For consistency, it is legal to write (SETF)"; (a) in my book, that should be >an error, (b) if it's not an error, why isn't there a definition using the >approprate & keywords? Consistency? Generating an "insufficient args" >error seems more consistent to me... The syntax specified in CLTL is: SETF {place value}* In CLTL's notation for macro syntax, this states that an arbitrary number of (place, value) pairs may be specified. The sentence you complain about is only restating the obvious so that even you could not miss this point. > >Then try explaining why SET only affects dynamic bindings (a most glaring >error, in my opinion). Again, how many years of training, understanding >and textbooks are suddenly rendered obsolete? How many books say >(SETQ X Y) is a convenient form of (SET (QUOTE X) Y)? Probably all >but two... Well, the times they are a changin'... Of course, if you understood lexical variables, you would understand why you can't compute a variable name at run time and then reference it. > >Then try to introduce them to DEFVAR, which may or may not get >evaluated who knows when! (And which aren't implemented correctly >very often, e.g. Franz Common and Golden Hill). It is true that DEFVAR's behavior is somewhat non-intuitive, but it is usually the "right thing" unless you are doing wrong things in your variable inits. This is an instance of the MIT philosophy of doing the right thing even if it is a bit more complicated (Like in ITS EMACS v.s. imitations, a subject which I could flame about with verbosity and irrationality comparable to yours). > >MEMBER is a perfect example. I complained to David Betz (XLISP) that MEMBER >used EQ instead of EQUAL. I only checked about 4 books and manuals (UCILSP, >INTERLISP, IQLISP and a couple of others). David correctly pointed out that >CL defaults to EQ unless you use the keyword syntax. So years of training, >learning and ingrained habit go out the window. How many bugs >will this introduce. MEMQ wasn't good enough? Of course you are wrong here, although only in a minor way. It uses EQL, like every other Common Lisp function that has an implicit equality test. This particular decision was agonized over for quite a while, but it was decided to change MEMBER in the interest of consistency (which I believe you defended earlier). > >While I'm at it, let me pick on the book itself a little. Even though CL >translates lower case to upper case, every instance of LISP names, code, >examples, etc are in **>> lower <<** case and lighter type. In fact, >everything that is not descriptive text is in lighter or smaller type. Yep, Digital Press botched the typesetting pretty badly. Of course, the reason that the code is in lower case is that everyone with any taste codes in lower case. The reason that READ uppercases is that Maclisp did. Flamingly yours... Rob MacLachlan (ram@c.cs.cmu.edu)