Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!uhog.mit.edu!sgiblab!pacbell.com!amdahl!netcomsv!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
Message-ID: <hbakerCxquDG.LEF@netcom.com>
Organization: nil
References: <37eb4h$k4f@vertex.tor.hookup.net> <CxMpD2.525@rheged.dircon.co.uk> <Pine.A32.3.91.941014091539.42306C-100000@swim5.eng.sematech.org>
Date: Sun, 16 Oct 1994 02:17:40 GMT
Lines: 58

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?  

Any language revision which more than doubles the size of an already
bloated language is putting nails into its coffin.  A large language
is very expensive to write and maintain a compiler for, and nearly
impossible to properly tune for each architecture.  If much of the
tuning cannot be done via extremely general purpose optimizations
(e.g., deep 'inlining'), then the user is stuck with poor performance
of the built-in stuff, and if the language isn't reflective, then he
can't even 'go under the hood' and fix it himself.

Any language revision which adds more stuff which is impossible to
compile efficiently without a huge number of special-purpose ad hoc
hacks in the compiler puts nails into the coffins of its vendors, as
well as those of its users who must explain to their management why
Lisp is slow and getting slower instead of faster.  (Exactly the same
complaint is true of Ada.)

More details in the following papers:

"Critique of DIN Kernel Lisp Definition", Lisp & Symb. Comput. 4,4
(Mar 1992), 371-398.  (Really a critique of Common Lisp itself).  In
my ftp directory.

"CLOStrophobia: Its Etiology and Treatment".  ACM OOPS Messenger 2,4
(Oct 1991), 4-15.  In my ftp directory.

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

The mere existence of a standardization committee which is known to be
making dramatic changes to a language provides enough of a 'FUD'
factor (fear, uncertainty, doubt) to damage the credibility of the
language.  Any dramatic changes in the language are guaranteed to
cause the marginal vendors to decide whether to 'fish or cut bait'.
In the Ada market, more than 50% of the vendors decided to bail out
rather than upgrade to Ada9X.

--------

This isn't to say that an 'object-oriented Lisp' isn't a good thing.
However, classes and methods grafted onto the back of a
non-class/method-oriented language end up looking like the hunchback
of Notre Dame.  Better that CLOS/Dylan should have been a totally new
language, without 450 pages of baggage to support.

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.

