Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!brahms.udel.edu!lkramer
From: lkramer@brahms.udel.edu (Laurence Kramer)
Newsgroups: comp.lang.lisp
Subject: Re: weird common lisp feature
Keywords: read, read-line
Message-ID: <18935@brahms.udel.edu>
Date: 21 Feb 91 14:46:04 GMT
References: <12413@helios.TAMU.EDU> <1991Feb21.104336.26012@Think.COM>
Organization: Quantum Software, Inc.
Lines: 32

Permit me to flame a while...  Last week I wrote a message that said
briefly that people doing AI R&D in C rather than Lisp needed their
heads examined.  Well, this common lisp "feature" mentioned further
reinforces another opinion I have:  People developing in common lisp
need their heads examined.  If I write (foo a) (foo2 b), I would certainly
expect foo to be evalled before foo2.  As a software developer I shouldn't
have to worry that the combination of foo and foo2 somehow is different
than most other functions I know about.  This is certainly in direct
opposition to the spirit of Lisp programming!

The problem with common lisp is not so much that it is too big, or that it
was written by a committee, etc.  The problem with common lisp is that
it was written more with an eye to the compiler than to the interpreter.

Do people programming in common lisp really need their heads examined?
No, they should be pitied because their options are few.

In an ideal world we would all be programming in muLisp.  It is beautiful,
small, efficient, extensible, and really embodies the spirit of what Lisp
should be.  Two big problems: it is imprisoned within DOS's 640k barrier
and isn't portable.  (An idea: everyone write letters to Al Rich and convince
him to write a portable muLisp.  We already tried this, but perhaps if more
people tried...)

So, what did we (Quantum Software) end up doing?  We bit the bullet and
wrote our own portable lisp in C (based very closely on muLisp).  XLisp is
ok, but obviously not up to an industrial strength standards.

(Sorry, sportsfans, we're really not interested in selling this Lisp, because
 we don't have the resources to support it outside of our organization.)

Larry