buff@pravda (Richard Billington) (05/01/91)
The following is a proposal for a new conference based on the annual meeting of the Symbolics Lisp Users Group (SLUG) model. The idea is to this year hold the SLUG conference in conjunction with a larger conference which would include other lisp vendors and their users. We (the SLUG board of directors) would appreciate your feedback and whether you'd be interested in attending. Our preliminary estimate is that we'd hold the conference in the Washington D.C. area in late Sept. Please let us know of conflicts. Lisp Users and Vendors Conference (LUV'91): A Lisp-Community Town Meeting RAISON D'ETRE This conference is a chance for the Lisp user community to meet in conjunction with the Lisp vendor community to learn about what we have to offer each other and to discuss issues of mutual concern. The primary focus of this first conference will be to enumerate the issues which keep lisp from being the clear language of choice, particularly in areas where it has lost that role, and determine how to address those issues. Lisp is an important programming language because it is general purpose, powerful, and easy to develop and maintain programs with. It is equally good as a tool for analysis and design as it is a tool for implementation. Because of these properties, many advances in program development technology have been pioneered using lisp. Some examples are object-oriented programming, integrated development environments, and machine-independent user interface systems. Lisp itself, and these tools, have enabled programmers to produce large, sophisticated software systems which would be difficult or impossible to develop and maintain in other languages. These software systems have been developed as a part of basic research, applied research, as well as in the commercial sector. Lisp is at an important crossroads. Many of the ideas first developed into reliable tools for the professional lisp programmer are beginning to appear for other languages. As a community, we must stress the pre-eminance of lisp as the language which has systematically lead the way in introducing and improving development tools; and to continue this leadership, we must determine what the course of future development of programming tools will be that will have the most benefit to the lisp programming community. GROUND RULES FOR VENDOR PARTICIPATION This is NOT a sales conference: it is a conference for users to get together and learn technical details about products, new and old, and to provide a focal point for input to the vendors about what our needs are. To this end, only management and technical representatives are invited to attend this conference. Further, NO NON-CONFERENCE FUNCTIONS - no hospitality suites, no specific vendor sponsored parties. PRELIMINARY AGENDA Monday and Tuesday: Tutorials some product/vendor specific, others more "community wide" - like CLIM and CLOS tutorials. We may want to also have vendor-specific technical sessions as well - i.e. sessions that are instructive technical sessions, but which aren't the sort of thing you pay extra money for as tutorial sessions. These have been offered as part of the general SLUG sessions in the past, but given there are a lot of additional things to do on W - F, perhaps some could get mixed in here. Tuesday evening: Vendor sponsored welcome to attendees. Wed morning: welcome and direction setting from the conf. organizers; welcome and important agenda items from each of the vendors. Wed afternoon: Lisp community issues such as formation of a Lisp user's group, standardization, how to get our management to change their attitude about lisp, etc. Wed. evening: Application "poster" session - I quote poster 'cause this could be demos ... wine and cheese should be served in conjunction. Thurs: vendor "mini-conferences": sessions about detailed state of companies, new products, specific user/vendor issues (like, specific user/vendor issues, as well as how to use vendor specific facilities optimally). Thurs evening: Refreshments, entertainment, and a generally good time. Fri morning: conclude "mini-conferences" Fri. afternoon: Plenary session - a "user group" summary of issues to be addressed over the coming year (one from each user group?); ditto vendors (one rep. from each gets to do a short talk); audience - panel Q&A session; summary talk from someone who's important and quick on their feet - that is, can do a reasonable job of summing up the conference and in particular the afternoon session.
ram+@cs.cmu.edu (Rob MacLachlan) (05/03/91)
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