Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!harlqn.co.uk!harlequin.co.uk!jason
From: jason@harlequin.co.uk (Jason Trenouth)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
In-Reply-To: simon@rheged.dircon.co.uk's message of Wed, 19 Oct 1994 21:55:46 GMT
Message-ID: <JASON.94Oct20132954@wratting.harlqn.co.uk>
Sender: usenet@harlequin.co.uk (Usenet Maintainer)
Organization: Harlequin Ltd, Barrington Hall, Cambridge UK
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> <Cxxwx0.1nC@rheged.dircon.co.uk>
Date: Thu, 20 Oct 1994 12:29:54 GMT
Lines: 252


On Thu, 13 Oct 1994, Simon Brooke wrote:

Simon> .... This was just about the time when X3J13 were driving their
Simon> nails into the coffin of LisP, ....

In article
<Pine.A32.3.91.941014091539.42306C-100000@swim5.eng.sematech.org>
"William D. Gooch" <goochb@swim5.eng.sematech.org> writes:

William> This seems to me to be extremely unfair to those who worked
William> hard to put together a comprehensive and IMO high-quality
William> standard for Common Lisp.  Do you have any justification for
William> this slam?  Did you offer your help?

>>>>> "Simon" == Simon Brooke <simon@rheged.dircon.co.uk> writes:

Simon>  To deal with your questions in reverse order:
Simon> 
Simon> (i) yes, I served on the British Standards Institution LisP
Simon> committee for a time (I'm not pretending my contribution was
Simon> particularly valuable).
Simon> 
Simon> (ii) There are a number of specific arguments I would advance
Simon> (a) as to the flawed nature of the Common LISP design, and (b)
Simon> to defend the claim that these flaws were a consequence of the
Simon> commercial/political axes being ground in X3J13.
Simon> 
Simon> (iia: Flaws in the language design)

Hi Simon,

I just thought I'd criticise your list of flaws in the language:

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

Many Lisp programmers did use in-core editing, but probably most did
not. The divide reflected the InterLisp vrs MacLisp-family divide.

In-core editing has disadvantages too. An entertaining snapshot of the
arguments between the two communities is captured in [1] and repeated
in [2].

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

What are their workarounds and why do they breach the standard?

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

I don't think that is true. There are LISP2 advocates and their
reasoning centers around ease of macrology. I believe KMP (Kent
Pitman) has co-authored a paper on the topic.

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

In think the case conventions were only widespread in the InterLisp
community.  

BTW case conventions for multi-word tokens are more often seen in
infix languages because it can be confusing (for the human reader) to
allow hyphens in tokens.

Personally, I find:

	lots-of-words-in-a-token

much much easier to read than:

	lotsOfWordsInAToken

If you really want to develop code in this style then CL provides
portable functions and parameters you can use: e.g. READTABLE-CASE and
*PRINT-CASE*.

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

Not true. By default, CL ignores the case that developers type and
shouts back at you.  Users source code is generally written in _lower
case_. Uncontrolled output is generally in upper case. But as I said
case I/O is user definable in CL.

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

It is true that sequence functions should probably be generic but that
is more of an implementation detail. CL vendors could use GF's under
the hood to do the dispatching.

In what way to sequence functions require Common LLisp to be large and
unwieldy? I've not heard this argument before.

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

Keyword arguments can make code that is evolving quickly much more
maintainable. CL is a great language for doing research and
development.

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

SETF is not only used for modifying list structure. It introduces an
abstract notion of "places". E.g. SETF is also used for setting CLOS
object slots.

The idea that potentially dangerous operations (like destructively
modifying list structure) should be protected through obfuscation is
itself dangerous.

SETF is not the direct equivalent of POKE. POKE is at the byte level
and doesn't respect HLL data structures.

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

Common LISP is indeed a large language with some spurious stuff in it.

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

The largest body of Lisp users was probably the MacLisp crowd.

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

There was certainly some rivalry, but I think conscious sabotage is
stretching things a little.

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

I don't think either decision is inexplicible. NB Case insensitivity
is just the default.

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

The MacLisp family had a large number of users.

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

Simon> I hope that you may be right, but do not myself agree. I
Simon> believe, and I guess that you do, that languages within the
Simon> LisP family offer at the very least a better programming idiom
Simon> than C++. Ten years ago, machines which could run a big LisP
Simon> system were at last becoming cheap, and all the major computer
Simon> vendors were showing a considerable interest in the language.
Simon> 
Simon> Five years later that interest had waned. It's no co-incidence,
Simon> I think, that this was contemporaneous with the introduction of
Simon> a new, 'standard' version of the language so complex that
Simon> compilers were exceedingly difficult to develop, optimise and
Simon> maintain, and so different from existing, well established
Simon> variants of the language that experienced programmers were at a
Simon> loss.

I think this last bit is untrue. Common Lisp is very much in the
tradition of the MacLisp family.

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

And Harlequin has been growing strongly since its foundation!

	Regards -- Jason

[1] R. M. Stallman and E. Sandewall, (1978), "Structured editors with
    a LISP", ACM Computing Surveys, vol 10, no. 4, December, pages
    505-508.

[2] Barstow, D. R. Shrobe, H. E. and Sandewall, E., (eds) (1984),
    "Interactive Programming Environments", McGraw Hill.
--
_____________________________________________________________________________
| Jason Trenouth,                        | EMAIL: jason@uk.co.harlequin     |
| Harlequin Ltd, Barrington Hall,        | TEL:   (0223) 872522             |
| Barrington, Cambridge CB2 5RG, UK      | FAX:   (0223) 872519             |
