Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!im4u!milano!rcp
From: rcp@milano.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: frustration with LUCID on Sun 3
Message-ID: <4443@milano.UUCP>
Date: Sat, 2-May-87 14:30:09 EDT
Article-I.D.: milano.4443
Posted: Sat May  2 14:30:09 1987
Date-Received: Sun, 3-May-87 06:21:23 EDT
References: <611@savax.UUCP>
Sender: rcp@milano.UUCP
Organization: MCC Software Technology Program
Lines: 58

In article <611@savax.UUCP> dove@savax.UUCP (webster dove) writes:
;We are trying to use LUCID 2.0 on a Sun 3/110 with their window
;package, and it seems that the least trivial error will leave a window
;on the screen blocking the other windows and essentially wedge the
;lisp (^C gets ignored etc.).  

There are at least 3 window packages for Lucid on the sun (incuding:
the Lucid window toolkit, common windows, Suns sunview interface).
Interfaces which are via the foreign function interface to "c" tend to
be fragile when an error occurs.  This robustness of ffi needs to be
improved. 

;On the Symbolics, one could click right to get a menu and kill the
;current window or hit ctrl-abort and get a lisp stream.  With this
;Lucid environment, things seem much less friendly.

Common Lisp does not define a standard process model for lightweight
processes sharing the same lisp environment.  This is an important
missing ingredient for the type of interaction you describe above.

;Also, the paging with 4 MBytes of ram is outrageous.

Have you tried using a lisp machine with only 4MB of RAM?  Actually
common lisps on unix systems seem to need more physical memory than on
a lisp machine.  8MB seems marginal on either machine.  16MB gives
good performance on either.

;This surprises me because I was quite happy with software development
;on the Symbolics, and had made the assumption that Lisp was at the
;root of that contentment.
;
;Now it seems that the implementation of things like the window system
;(doesn't use flavors under Lucid), condition handling (non-existant
;under Lucid), the debugging facilities (not window oriented/mouseable
;under Lucid), the multi-process nature of the Symbolics and the polish
;of their system (things like command line editing aren't available
;under Lucid) were what I really liked about using the Symbolics.

All of these are good points.  We have had good success using gnu
emacs as a support environment for common lisp development on the Sun.
It was easy to add such features as common lisp documentation,
function name completion, and package support.  In most regards I
consider the gnu emacs editor support we have for lisp to be better
than zmacs on the lisp machine.  Now that there is a Common Lisp
Object System specification, I expect that reasonable vendor support
for the items you mention isn't too far away.  There will always be
an advantage to debugging on a tagged architecture machine, but in
most respects there is no reason why the development environment can't
be as good.

-Rob

ps: these are purely my personal opinions of course ...
--
  Robert C. Pettengill, MCC Software Technology Program
  P. O. Box 200195, Austin, Texas  78720
  ARPA:  rcp@mcc.com            PHONE:  (512) 338-3533
  UUCP:  {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp