Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!ames!lll-lcc!well!jjacobs
From: jjacobs@well.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <2573@well.UUCP>
Date: Thu, 12-Feb-87 01:08:39 EST
Article-I.D.: well.2573
Posted: Thu Feb 12 01:08:39 1987
Date-Received: Fri, 13-Feb-87 02:10:24 EST
Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs)
Distribution: comp.lang.lisp, mod.ai, comp.ai
Organization: CONSART Systems Inc., Manhattan Beach, CA
Lines: 122
Summary: Preventing some old flames...


Some comments on "Against the Tide of Common LISP".

First, let me point out that this is a repeat of material that appeared
here last June.  There are several reasons that I have repeated it:

1) To gauge the ongoing change in reaction over the past two years.
The first time parts of it appeared in 1985, the reaction was
uniformly pro-CL.

When it appeared last year, the results were 3:1 *against* CL, mostly
via Mail.

Now, being "Against the Tide..." is almost fashionable...

2)  To lay the groundwork for some new material that is in progress
and will be ready RSN.

I did not edit it since it last appeared, so let me briefly repeat some
of the comments made last summer:

I.  My complaint that "both dynamic and lexical makes the 
performance" even worse refers *mainly* to interpreted code.

I have already pointed out that in compiled code the difference in
performance is insignificant.

2.  The same thing applies to macros.  In interpreted code, a
macro takes significantly more time to evaluate.

I do not believe that it
is acceptable for a macro in interpreted code to by destructively
exanded, except under user control.

3.  SET has always been a nasty problem;  CL didn't fix the problem,
it only changed it.  Getting rid of it and using a new name would
have been better.

After all, maybe somebody *wants* SET to set a lexical variable if that's
what it gets...

I will, however, concede that CL's SET is indeed generally the desired
result.

4.  CL did not fix the problems associated with dynamic vs lexical
scoping and compilation, it only compounded them.   My comment
that

>"lexical scoping was and should be a compiler OPTIMIZATION"

is a *historical* viewpoint.  In the 'early' days, it was recognized
that most well written code was written in such a manner that
it was an easy and effective optimization to treat variables as
being lexical/local in scope.   The interpreter/compiler dichotomy
is effectively a *historical accident* rather than design or intent of the
early builders of LISP.

UCI LISP should have been released with the compiler default as
SPECIAL.  If it had been, would everybody now have a different
perspective?

BTW, it is trivial for a compiler to default to dynamic scoping...

5. >I  checked in Steel; lo and behold, tis true (sort of).
>In 2 2/3 pages devoted to SETF, there is >> 1 << line at the very bottom
>of page 94!  

I was picking on the book, not the language.  But thanks for all
the explanations anyway...

6.  >"For consistency, it is legal to write (SETF)"

I have so much heartburn with SETF as a "primitive" that I'll save it
for another day.

7. >MEMBER used EQ instead of EQUAL.

Mea culpa, it uses EQL!

8.  I only refer to Common LISP as defined in the Steele Book, and
to the Common LISP community's subsequent inability to make
any meaningful changes or create a subset.  (Excluding current
ANSI efforts).

Some additional points:

1.  Interpreter Performance

I believe that development under an interpreter provides
a substantially better development environment, and that
compiling should be a final step in development.

It is also one of LISP's major features that anonymous functions
get generated as non-compiled functions and must be interpreted.

As such, interpreter performance is important.

3.  "Against the Tide of Common LISP"

The title expresses my 'agenda'.  Common LISP is not a practical,
real world language.

It will result and too expensive.  To be accepted, LISP must be able to run
on general purpose, multi-user computers.

It is chtance of other avenues and paths of
development in the United States.

There must be a greater understanding of the problems, and benefits
of Common LISP, particularly by the 'naive' would be user.

Selling it as the 'ultimate' LISP standard is dangerous and
self-defeating!

 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