Re: Lisp considered unfinished

[kanderso@bitburg.bbn.com (Ken Anderson)]

In article <3qnek3$mk@Yost.com> yost@Yost.com (Dave Yost) writes:
   >Amazing.  Anything should be allowed as an incidental tool.  A researcher
   >has to pick the best language for his or her group.  Groups put a lot of
   >effort in developing a good tool set for the language they work with.  For
   >an external reviewer to base his/her decision on an incidental tool is
   >stepping out of bounds.  Faulting a dynamic language is being particularly
   >insensitive to prototyping needs of research.  The reviewer is probably
   >someone who still views Lisp as the Lisp 1.5 that some programming
   >language texts cover.

   Denial.

   I think Lisp implementers should take this as a wake-up call.

Everyone, not just implemntors need to hear this.

   There are other warnings.
     * Lucid went out of business

Why was that?  The hearsay says the C++ side brought the house down.

     * CMUCL was abandoned, and the people are working on Dylan

Perhaps they did not believe that Lisp had the seeds for its own renewal.

     * MCL was abandoned for 2 years before being revived
     * The GARNET project has left lisp behind and has gone to C++.
       It's now 3 times faster, and more people are interested in it.

This "3" is an interesting number, where does it come from?  While people
often mention a factor of 10 difference between Lisp and C, the Lisp
version is usually junk (sorry i only have two examples of this).  The
analysis i've done on admitedly small programs, suggests reasonable factors
are less than 1.5.  Garnet is a sizable chunk of code, so as an example of
a real application, understanding the performance and other differences
between the Lisp and C++ versions would be very valuable to us.  I can find
the Garnet Lisp code from the Lisp Faq (ftp a.gp.cs.cmu.edu
/usr/garnet/garnet), but where is the C++ code?

   Surely there are many others.

1.  Any expert system shell that is now in C or C++.

2.  Anyone who would rather be programming in Lisp than what they are
programming in.  Here are two of the projects i'm working on:

2P1: Coding in C++, even though i'm implementing a very simple scheme like
parallel language (without scheme syntax).  I prototype in Lisp and hand
code a threaded interpreter that uses C++ objects at runtime.

2P2: Coding in Scheme, although Lisp would be more effective.  This is
because Lisp is "tainted" which was Henry's point, and Scheme can be hidden
inside "a C application".  Also, the Scheme is flexible enough for those
who realize they want it on the inside.

   As far as I can tell, ANSI lisp is being treated as a huge
   plateau, as if there is nothing interesting left to do, or
   as if any further changes would be too hard to negotiate.

   What about speed?  size?  C/C++ interoperability?

I think users and vendors working together can do a lot here.

   These issues have been untreated emergencies for some years now.

It is easy to say "we did that 10 years ago in Lisp".  However, it doesn't
mean much if we can't deliver it to the people who want it now.  We need to
collect and focus our capabilities so we can.
--
Ken Anderson 
Internet: kanderson@bbn.com
BBN ST               Work Phone: 617-873-3160
10 Moulton St.       Home Phone: 617-643-0157
Mail Stop 6/4a              FAX: 617-873-2794
Cambridge MA 02138
USA