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: <2601@well.UUCP>
Date: Wed, 18-Feb-87 02:14:01 EST
Article-I.D.: well.2601
Posted: Wed Feb 18 02:14:01 1987
Date-Received: Thu, 19-Feb-87 06:46:26 EST
Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 109


In <141@lmi-angel.UUCP>, Bob Krajewski writes:

>>When it appeared last year, the results were 3:1 *against* CL, mostly
>>via Mail.
>
>What exactly are you trying to imply here ?  What were the circumstances of
>rejection ?

Simple!  Last time I started this discussion, most of the comments
received were private, not public, and most of them were of the form "I
don't like CL much either"!

>>I have so much heartburn with SETF as a "primitive" that I'll save it
>>for another day.
>
>Well, I'd like to hear them.  It would be interesting to see what your
>objections are.

Real Soon Now :-)

>>7. >MEMBER used EQ instead of EQUAL.
>>
>>Mea culpa, it uses EQL!
>
>Nitpicking aside, this is hardly arbritrary -- remember that since Common
>Lisp is a new dialect, there was only a secondary consideration in being
>compatible with other Lisp dialects.

Foolish me, I believed the book!

>In non-specialized implementations, this is less likely to be true if
>not many conventions of a ``virtual Lisp machine'' are honored in compiled
>code.

At what point should a compiler go for full out machine dependent 
optimization, as opposed to honoring a "virtual LISP machine"?
(Not that any such VLM is defined by Common LISP anyway).

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

I was referring to CONS'ed functions created at run time.  Sorry if
that wasn't clear...

>OK, back to the crusade...
>
>>It will result and too expensive.  To be accepted, LISP must be able to run
>>on general purpose, multi-user computers.
>
>It takes a consultant to come up with conclusions like this, and
>requirements like this...
>
>>There must be a greater understanding of the problems, and benefits
>>of Common LISP, particularly by the 'naive' would be user.

It takes a LISP Machine Vendor to ignore that large a market :-)

Seriously, how are sales of LISP machines to the commercial sector?
What percentage of sales are to Universities and DARPA/DoD funded
R&D?  How many LISP machines have been sold to banks?  To
Insurance Companies?  To aerospace companies?

The simple truth is that the perception that LISP is big and slow
is extremely common.  It also happens to be *true*.  The ability
of LISP implementors to dream up features that outstrip
improvements in hardware has been going on since before I
wrote my first function in LISP, finally resulting in a storage
management scheme where 50% of memory is always unused :-)

>>Selling it as the 'ultimate' LISP standard is dangerous and
>>self-defeating!
>
>Who said that ?  Common Lisp is not a step forward in terms of Lisp
>``features.''  By reining in the spec and getting diverse implementors to
>agree on something, I can write a program on a Sun, and have it work on
>(say) a Lisp Machine (Zetalisp), a Silicon Graphics box (Franz Common Lisp),
>a DEC-20 (Hedrick's Common Lisp), a VAX (NIL or DEC Standard Lisp), and so
>on.

Boy, are you a dreamer! Last year, when I made the rounds of non-SPICE
derived Common LISPs, I managed to break every one within 10 minutes!
And if you can get anything to run in NIL, please let me know how!

And of course, anything that gets developed on any of the LISP
machines is guaranteed to have non-CL code in them!

I'm not clear on one thing; when you say "reining in the spec", are
you refering to Common LISP as 'being a reined in spec' or
that Common LISP needs to be 'reined in'.

>At least now there is a Lisp which is no more repugnant
>than C (actually, at lot less, in my freely admitted biased opinion) as a
>portable programming language

This is stretching the term "portable"; one assumes that portable
means "easily" transported :-)  Code written in Common LISP
may be portable, but the language itself sure isn't!!!

>Robert P. Krajewski

 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