Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cuae2!ihnp4!ptsfa!lll-lcc!styx!ames!think!mincy
From: mincy@think.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <1165@think.UUCP>
Date: Fri, 13-Feb-87 09:10:13 EST
Article-I.D.: think.1165
Posted: Fri Feb 13 09:10:13 1987
Date-Received: Sat, 14-Feb-87 15:29:46 EST
References: <2573@well.UUCP>
Sender: usenet@think.UUCP
Reply-To: mincy@godot.think.com.UUCP (Jeffrey Mincy)
Distribution: comp.lang.lisp, mod.ai, comp.ai
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 38

In article <2573@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:
>Some additional points:

>1.  Interpreter Performance
>I believe that development under an interpreter provides
>a substantially better development environment, 
Absolutly.  
>and that compiling should be a final step in development.
I find that I almost always run code compiled, even code under
development.  The reasons are, most silly typos are caught by 
the compiler, such as mispelled variables and functions.
When I have bugs, the lisp debugger is usually sufficient on
compiled functions.  If I have an unually hard bug to understand,
then I might run interpreted with step.  

>It is also one of LISP's major features that anonymous functions
>get generated as non-compiled functions and must be interpreted.
Most anonymous functions (I presume you mean lambda expressions where 
you write #'(lambda (...) ...) in your code) will get compiled.
Only by saying '(lambda ...) or consing one up on the fly will you 
get anonymous interpreted functions.

>As such, interpreter performance is important.
Yes, but not *that* important.

>3.  "Against the Tide of Common LISP"
>The title expresses my 'agenda'.  Common LISP is not a practical,
>real world language.
I find that attitude most unfortunate.  If you want to say Common LISP
is a large language, and that it is difficult to implement well - then
I would agree with you totally.  But I have to disagree strongly with
this statement.  

> Jeffrey M. Jacobs


-- jeff
seismo!godot.think.com!mincy