Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!mvb.saic.com!eskimo!cgweav
From: Clayton Weaver <cgweav@eskimo.com>
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
In-Reply-To: <843335875snz@wildcard.demon.co.uk>
X-Nntp-Posting-Host: eskimo.com
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.SUN.3.95.960922111121.9319B-100000@eskimo.com>
Originator: cgweav@eskimo.com
Sender: news@eskimo.com (News User Id)
Organization: Eskimo North (206) For-Ever
References: <3052297391247606@naggum.no> <843335875snz@wildcard.demon.co.uk>
Mime-Version: 1.0
Date: Sun, 22 Sep 1996 18:46:25 GMT
Lines: 45

Check the viewpoint of the Garnet developer's in the Garnet faq. Their
consensus was that the C++ code (at least with the compilers in use on the
platforms they tested on) was simply faster for a given programming task
than the lisp code. (Incidentally, there is a patch on the clisp ftp site
for improving performance with garnet). You only have to program it a few
times (development plus maintenance). Your customers have to use it a
million times. 

I like lisp for the lack of syntactic idiosyncrasies. It may look strange
to the newbie on first sight, but one can learn it faster than a C-like
language, because there are less syntactic details and context-dependent
semantic gotchas to remember. A few simple constructs, and you can build
anything with it (though I wouldn't use it for systems code that runs
directly on the metal). 

But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog; I
just expect it to be working sooner with less of my time spent to get it
debugged. Lisp makes it easy to manage scope.

But if I have a commercial product for ram- and cpu-limited hardware, my
customers don't care how difficult or expensive the development process is
for me. They only look at the price tag and the job they want done. If my
competitor writes a program in C/C++ that does the same thing correctly 
three times faster for the same price, that is what they will buy.

Lisp's commercial strength seems to be in complex code that would take a
prohibitively long time to develop and debug in procedural languages,
running on hardware well beyond the average desktop (with doubtless some
exceptions). As the average desktop gets faster, lisp may find a
resurgence of popularity in commercial programming environments. Fast
enough for the customer is fast enough, and programming labor costs should
be lower than for a C++ shop.

But that only applies to desktops as they are now. If you look at machines
like "network computers", the perspective is going to be similar to that
for embedded systems programming. Ram/rom is part of unit cost, and lisp
in most implementations makes more luxurious use of than other languages
that can get the job done.

Regards, Clayton Weaver  cgweav@eskimo.com  (Seattle)





