Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.duke.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!EU.net!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
Message-ID: <Cy1H5H.5I8@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute-alter.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <Pine.A32.3.91.941014091539.42306C-100000@swim5.eng.sematech.org> <hbakerCxquDG.LEF@netcom.com> <Cxxwx0.1nC@rheged.dircon.co.uk>
Date: Fri, 21 Oct 1994 20:05:41 GMT
Lines: 161

In article <Cxxwx0.1nC@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:

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

This "load" is something like two characters (C-z e) in the Emacs
mode I use.  I'd much rather have that than DEDIT!

I don't think the differences between these two styles are all
that great.  Obviously, some people disagree with this ...

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

As far as I can tell, there's nothing on page 347 or anywhere else
that prevents a Common Lisp system from retaining comments in various
ways.  Perhaps the particular workarounds you mention violate
something, but I don't know what it is.  (But then I don't know
what those workarounds do.)

>  A language definition which
>prevents established practitioners working in their preferred manner
>is broken.

They were not established practitioners of Common Lisp in any case.  :-)

The idea that Lisp is a single language has done -- and is doing --
tremendous damage.  Common Lisp is just one Lisp, not all Lisps.


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

What does that have to do with Lisp-1 vs Lisp-2?


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

Good riddance!  :-)

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

False.

It's in part because of these wild attacks on Common Lisp in the UK
that I decided to do something about case-sensitivity, BTW.  Hence
readtable-case and the end of this particular target of opportunity.


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

Just how "huge" is this "monolithic" structure, anyway?


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

Franz Lisp handled all that (except &KEY) in a not-very-large macro.


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

It is not any equivalent of POKE.  It is very like assignment in
most languages.  You can assign to variables and to slots of
structs and to array elements.  If conses were the one exception,
people would complain about non-orthogonality.

This kind of exaggerated criticism substantially weakens your
case, in my opinion.


>(iib) These flaws are consequences of political goals


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

But they didn't make it very different from MacLisp.

>This allegation explains both the comments system and the choice of
>LISP2, two decisions each of which are otherwise inexplicable. 

They are *easily* explained in other ways.  Just like MacLisp,
for instance.  A number of other Lisps are also Lisp-2s.

Of course, there may have been several reasons to want to follow
MacLisp rather than InterLisp.  Perhaps making things more difficult
for Xerox was one of them.  Preventing Interlisp from being imposed
as a standard (ARPA was wanting a single Lisp, I seem to recall)
was very likely a factor.

But there's nothing especially evil about basing a Lisp on
MacLisp.  I'd prefer that to many alternatives.


>I am prepared to believe the claim that the case-insensitive reader was a
>requirement of the United States Department of Defense.

See above.  There was no opposition to readtable-case that had
any DOD component I could detect.


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

That may be, but your evidence is not very convincing.


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

I had no trouble adapting, but I was using Franz Lisp which is
very like MacLisp.

-- jeff
