Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston.ans.net!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
In-Reply-To: hbaker@netcom.com's message of Sun, 16 Oct 1994 02:17:40 GMT
Message-ID: <Cxxwx0.1nC@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <37eb4h$k4f@vertex.tor.hookup.net> <CxMpD2.525@rheged.dircon.co.uk> <Pine.A32.3.91.941014091539.42306C-100000@swim5.eng.sematech.org> <hbakerCxquDG.LEF@netcom.com>
Date: Wed, 19 Oct 1994 21:55:46 GMT
Lines: 150

   In article
   <Pine.A32.3.91.941014091539.42306C-100000@swim5.eng.sematech.org>
   "William D. Gooch" <goochb@swim5.eng.sematech.org> writes:
   >On Thu, 13 Oct 1994, Simon Brooke wrote:
   >
   >> .... This was just about the time
   >> when X3J13 were driving their nails into the coffin of LisP, ....
   >
   >This seems to me to be extremely unfair to those who worked hard to put 
   >together a comprehensive and IMO high-quality standard for Common Lisp.  
   >Do you have any justification for this slam?  Did you offer your help?  

To deal with your questions in reverse order: 

(i) yes, I served on the British Standards Institution LisP committee
for a time (I'm not pretending my contribution was particularly
valuable).

(ii) There are a number of specific arguments I would advance (a) as
to the flawed nature of the Common LISP design, and (b) to defend the
claim that these flaws were a consequence of the commercial/political
axes being ground in X3J13.

(iia: Flaws in the language design)

(iia1) Prior to the definition of Common LISP, many LisP programmers
used an in-core development style. This style of development has
significant advantages: the development cycle is edit/test rather than
edit/load/test. More significantly, the code of a function actually on
the stack can be edited. By definition (CLtL 1, p347) Common LISP
comments are not read. Consequently, code edited in core loses its
documentation.

Richard Barbour's Procyon workaround, and the Envos Medley workaround,
are technically in breach of the standard definition, which
effectively prevents in-core development. A language definition which
prevents established practitioners working in their preferred manner
is broken.

(iia2) I don't think anyone any longer defends the decision to choose
a LISP2. It is especially true in LisP that code *is* data.

(iia3) Before the development of Common LISP a number of typographical
tricks were widespread in the LisP community which greatly assisted
the readbility of code. As examples, it was common to capitalise
theInitialLettersOfEmbbeddedWords in names. Similarly, we used to have
a convention that functions, methods etc had names Which Started With
a Capital Letter, whereas other variables had names which started in
lower case. INCOMMONLISPTHISISNOLONGERPOSSIBLE. Any language which
cannot tell the difference between an atom and AN ATOM is broken.

To put it another way, Portable Standard LisP (for example) is a
language for poets, but in Common LISP you can only shout.

(iia4) The implementation of the sequence functions is a mess. It's a
shame, because one can admire the o'erleaping ambition, but such a
huge monolithic structure is required to make it work that any Common
LISP environment has to be unwieldy. If Common LISP had been
object-oriented from the bottom up, a la EuLisP, it would have worked;
but given that decision wasn't taken (and that really isn't X3J13's
fault -- O-O was too new at the time), it would have been better to
admit that lists and vectors are fundamentally different things.

(iia5) I remain unconviced that keywords in lambda-lists are a good
idea. A number of points here: it is fundamental to the nature of LisP
that it is syntax-less and keyword-less -- that's a lot of what gives
it it's elegance, and what allows a LisP interpreter to be so small
and simple. A Common LISP interpreter must include a parser to handle
lambda lists, and once again is neither small nor simple.

(iia6) I have complained often enough before about the abhomination,
SETF. I rehearse my objections briefly. Destructively altering lists
may be dangerous, and should always be done consciously and with care.
If you use RPLAC, you know you what you are doing. SETF makes
destructive change invisible to the naiive user: it says 'take this bit
of memory, I don't know where it is, I don't know who owns it, I don't
know who else is holding pointers to it, and trample all over it'.
It's direct equivalent is the BASIC keyword, POKE. I *shudder*.

Note that in critiqueing the language definition, I have not
reiterated Henry Baker's objections (see message id
<hbakerCxquDG.LEF@netcom.com>) to the sheer size of the language as
defined, although I share them, and for very much the reasons he
states.

(iib) These flaws are consequences of political goals

At the time of the formation of X3J13, overwhelmingly the largest
company seriously involved in the LisP business was Xerox. Xerox's
InterLISP was big and bloated and inconsistent enough, God knows, but
it was nevertheless a wonderful programmers toolkit. Furthermore,
the Xerox D series machine, although expensive in itself, was very
substantially cheaper than competing LisP machines.

Given this circumstance, I am convinced by and happy to repeat
publicly the allegation that has been made frequently in the past that
the essential aim of a substantial number of the participants in X3J13
was to make Common LISP as different as possible from InterLISP, in
order to make it more difficult for Xerox to compete. 

This allegation explains both the comments system and the choice of
LISP2, two decisions each of which are otherwise inexplicable. I am
prepared to believe the claim that the case-insensitive reader was a
requirement of the United States Department of Defense.

In summary, I claim that in a number of instances, X3J13 deliberately
and knowingly chose the less good of technical choices, in order to
produce a language closer to that of the smaller vendors, and further
from that of Xerox.

You say:

   >I don't think the X3J13 work in any way contributed to the slump in the 
   >Lisp market, which was well underway before the result of their efforts 
   >became widely available.

I hope that you may be right, but do not myself agree. I believe, and
I guess that you do, that languages within the LisP family offer at
the very least a better programming idiom than C++. Ten years ago,
machines which could run a big LisP system were at last becoming
cheap, and all the major computer vendors were showing a considerable
interest in the language.

Five years later that interest had waned. It's no co-incidence, I
think, that this was contemporaneous with the introduction of a new,
'standard' version of the language so complex that compilers were
exceedingly difficult to develop, optimise and maintain, and so
different from existing, well established variants of the language
that experienced programmers were at a loss. 

Although, as I say, I believe that LisP is at least as good as the
languages in common use today as a language for the development of
complex software systems, I doubt whether its decline can now be
arrested.  I do not believe your claim that '...the slump in the LisP
market...'  was '...well underway...' in 1984, when the aluminium book
was published. Remember, the middle eighties were the period of the
Japanese '5th Generation Project', the British Alvey Programme, and a
number of similar initiatives througout the world. The same period saw
the founding of Harlequin and the commercialisation of POPLOG. These
things taken together seem to me to indicate considerable strength in
the LisP market.

I believe that the slump (but am prepared to listen to contrary
evidence) began subsequent to the publication of the aluminium book.
An argument _post hoc ergo propter hoc_ is liable to be flawed, I
know. That doesn't make it false.
-- 
---------------
"There is no point in making further promises now about reducing
taxation: nobody believes us." Edward Heath, October 1994
