Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!gatech!lll-lcc!well!jjacobs
From: jjacobs@well.UUCP
Newsgroups: comp.lang.lisp
Subject: Against the Tide of Common LISP
Message-ID: <2603@well.UUCP>
Date: Wed, 18-Feb-87 02:22:08 EST
Article-I.D.: well.2603
Posted: Wed Feb 18 02:22:08 1987
Date-Received: Thu, 19-Feb-87 06:47:11 EST
References: <2601@well.UUCP>
Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 83


In, <1137@spice.cs.cmu.edu>, Rob MacLachlan writes:
>>Subject: Re: Against the Tide of Common LISP
>>Date: 13 Feb 87 19:00:00 GMT
>>Nf-From: uicsrd.CSRD.UIUC.EDU!sharma    Feb 13 13:00:00 1987
>>
>>       There is a pretty good critique of Common Lisp in :
>>
>>       "A Critique of Common Lisp" by Rodney Brooks and Richard Gabriel 
>>(Stanford). It appeared in the proceedings of the 1984 ACM Symposium on
>>Lisp and Functional Programming.
>
>Yeah, this paper is reasonably coherent, but should be taken with a grain 
>of salt.  Some of the arguments in it are semi-bogus in that they present a
>problem, but don't present simple, commonly used solutions that largely
>solve the problem.

>For example, in one section complaining about the inefficiency of the
>complex calling mechanisms and their use in langauge primitives, they
>basically construct a straw man out of SUBST (or some similar function).
>
>What they do is observe that SUBST is required to take keywords in Common
>Lisp and that the obvious implementation of SUBST is recursive.  From this
>they leap to the conclusion that a Common Lisp SUBST must gather all the
>incoming keys into a rest arg and then use APPLY to pass the keys into
>recursive invocations.  If this was really necessary, then it would be a
>major efficiency problem.  Fortunately, this is easily fixed by writing an
>internal SUBST that takes normal positional arguments, and then making the
>SUBST function call this with the parsed keywords.  It is also easy to make
>the compiler call the internal function directly, totally avoiding keyword
>overhead.
>
>Now presumably the authors knew that this overhead could be avoided by a
>modest increment in complexity, but this isn't at all obvious to readers not
>familiar with Common Lisp implementation techniques.

Ok, let's try another example.  Let's assume that SUBST is contained in
a loop requiring 1,000,000 executions.  What "largely" solves this problem?

And to prove my case, let me quote from a REAL EXPERT:

"Common LISP has very powerful argument passing mechanisms.
Unfortunately, two of the most poweful mechanisms, rest arguments
and keyword arguments, have a serious performance penalty
in Spice LISP.

...

Neither problem is serious unless thousands of calls are being made
to the function in question..."

- Spice LISP User's Guide, Chapter 5, Efficiency by Rob MacIachlan.

Of course the real problem with Common LISP is that the user has
no choice; there are no alternate primitives which don't involve the
keyword overhead, so the experienced user must instead rely on the
implementor for efficiency.  There is no guarantee, or even good estimate,
how the efficiency will vary from machine to machine, or implementation
to implementation, thus offsetting some of the great claims of
portability.  (What runs well on one implementation may
run terribly on another).

>I also point out that, despite any misgivings voiced in the paper, Gabriel
>is a major player in Lucid Inc., whose sole product is a Common Lisp 
>implementation.  Evendently he believes that it is a practical, real-world
>programming language.

A man who combines good aesthetic judgement with good business
judgement.  Sell 'em what they want, not what they need!
After all, "nobody ever went broker by underestimating
the taste of the American consumer":-)

>  Rob


 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