Xref: utzoo comp.lang.lisp:4864 comp.lang.scheme:2436
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!spool.mu.edu!uunet!tut.cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!ram
From: ram+@cs.cmu.edu (Rob MacLachlan)
Newsgroups: comp.lang.lisp,comp.lang.scheme
Subject: Re: LUV'91: A Lisp-Community Town Meeting
Message-ID: <1991May2.225739.18378@cs.cmu.edu>
Date: 2 May 91 22:57:39 GMT
References: <1328@mephisto.edu>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon
Lines: 41


Well, I'll be there to talk about CMU Common Lisp.  Hopefully we can get
diverse enough attendence to form a general Lisp user community, instead of
just a 12-step program for Symbolic users in recovery.

There does seem to be a lot of dithering and soul-searching the Lisp
community these days.  I don't think there's any good reason why people are
as worried as they are.  Sure, C/Unix is more successful than Lisp, and is
starting to have some of the environment features we've had for ten years.
And new ideas like ML are starting to nip at some of the more experimental
application areas.  But Lisp is used more than ever before, and machines
that can run a full Lisp system are now well down under $10k.

Lisp systems have often tried to be an "island unto themselves", but this
insularity is rapidly fading given the wide availability of systems worth
building on top of.  Now that window systems are well enough understood to be
written in C, we can take them for granted, and move on to the next thing.

A broadly categorized agenda for Lisp development is:
 -- Fix the areas where Lisp compares poorly with other current programming
    environments:
     - Improve serious efficiency problems (type checking, number
       crunching, compilation efficiency models that are incomprehensible
       to users.)
     - Bring the Lisp development environment up to par in functionality:
       source level debugging, version control, automatic dependency
       analysis.
 -- Make Lisp better at doing what it does well:
     - Improve functionality and efficiency of object oriented programming.
     - Make meta-programming (macros, functionals, etc.) easier to use
       efficiently.
     - Develop de-facto standard programming environments (editors,
       browsers, etc.)
     - Generalize the Lisp heap into a persistent database.

I have already mentioned on comp.lang.lisp some of the ways in which CMU CL has
addressed the problems I mention above.  We would like to share our
public-domain implementation effort with vendors and users, and we also would
like to generate some exciting new ideas for Lisp programming environments.

  Robert MacLachlan