Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!well!jjacobs
From: jjacobs@well.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <2581@well.UUCP>
Date: Fri, 13-Feb-87 22:57:38 EST
Article-I.D.: well.2581
Posted: Fri Feb 13 22:57:38 1987
Date-Received: Sun, 15-Feb-87 00:26:34 EST
Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 122


In <131@spice.cs.cmu.edu> Rob MacLachlan writes, without using any
four letter words or sexual innuendoe!  The improvement in his 
vocabulary and manners since last summer is to be commended!

Unfortunately, his reading skills have not improved as much.

In general, I do not hold most of the views that he attributes to me,
and his ability to misinterpret what I write amazes me, particularly
since he has already seen most of this discussed previously.

I'm sure his leaping to irrelevant and unwarranted conclusions is 
already legion, as is his rapier wit, subtle sarcasm, and debating
society method of argumentation.

As such, I will only reply to those points of his which deal with
my original arguments, or which need addressing, such as his
apparent lack of understanding of the basic issues of software
engineering!

>>
>>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.

Read the paragraph again Rob!

>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.

Gee, just what the world needs; deliberately vague specs!!!

(And the COMMON LISP effort certainly doesn't begin to achieve
what the rest of the world considers a "standards effort")

>>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.

How to win friends and influence people!  I hope Rob gets tenure
at CMU, cause he might have a hard time getting ajob elsewhere.

>>As a last shot; most of the fancy Expert Systems (KEE, ART) are implemented
>>Common LISP.  Once again we hear that LISP is "too slow" for such things,
>>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.

Many vendors have *already* abandoned *compiled* Common LISP!
Interpreter speed had nothing to do with it.

>>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...

And I'm supposed to be ignorant about building compilers??? 

>>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.

There is a *BIG* difference between what I say and "hinting"!  The 
failed attempt to create a subset is sufficient proof of that..

Any *true* core' exists only in Rob's imagination!

>>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.

Good standards practice = vague and poorly defined?????

>  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.

Oh, I see.  Expecting understandable, consistent results is an 
unnecessary restriction on the implementor!!!

>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.

B.S!  All the compiled code for SET need do is check that the first argument
be lexically equivalent to a lexically apparent variable and change
the appropriate cell, stack location, or whatever.  Easy for a compiler
to do!

(This may not be what a lot of people *want*, but it is possible).

>Flamingly yours...
>                   Rob MacLachlan (ram@c.cs.cmu.edu)

 Jeffrey M. Jacobs
 CONSART Systems Inc.
 Technical and Managerial Consultants
 P.O. Box 3016, Manhattan Beach, CA 90266
 (213)376-3802
 CIS:75076,2603
 BIX:jeffjacobs
 USENET: jjacobs@well.UUCP