Symbolics & Sun-3 + Lucid Dev Envs

[Cliff Lasser <CAL@think.com>]

    Date: 29 Apr 1987 12:23-EDT
    From: VERACSD@a.isi.edu

    I'm interested in the viability of the Sun-3/160 running Lucid Common Lisp
    (with Lucid's version of Flavors) as a Lisp development environment.
    My standard for the comparison are Symbolics 36xx's, which I have a 
    strong predilection toward.

    I'm especially interested in opinions/remarks by experienced Symbolics
    programmers who have used Sun-3's with Lucid for more than a few hours.
    Some specific areas I would like to see addressed are:


We recently ported a large portion of our Connection Machine Software to
Lucid Common Lisp, I think around 150,000 lines of code.  At present the
system runs on Lucid Lisp under Vax Ultrix.  Ultrix Lucid Lisp is very
close to Sun Lucid Lisp.


	    o the completeness is Lucid's Flavors

We don't use flavors anymore.  For portability sake, we decided to use
only pure Common Lisp except where not possible.  Lucid Lisp is very
good if portability is a major concern.  Lucid must have a bunch of
lawyers reading the CL manual.  They are unbelievably strict and seem to
always follow the manual to the letter.  This is sometimes annoying
because Symbolics CL contains a fair number of "enhancements" that are
not portable.

	    o the quality of editing and debugging tools

Editor:  They provide an Emacs from which one can do incremental
compilation.  However it doesn't quite work right and is easy to wedge
by hitting control-c at the wrong time.  And if you wedge lisp, you lose
all your editor buffers!  As a result, almost all of us use Lucid from
inside GMACS.

Debugging: The debugger is fairly primitive compared to Symbolics'.  You
will learn that all your code must be compiled with speed 0, safety 3 if
you hope to debug a large system.  This is because the Lucid compiler
optimizes out quite a bit of stuff (tail recursion for example) and it
can be impossible to determine where in the program an error occured.
Disassembled functions are impossible to read so one often has to resort
to sprinkling print statements throughout the code being debugged.  
  The overall robustness of the system is questionable.  Hitting a
control-c during the execution of a program is dangerous to the health
of your lisp.  At some point later on, you may get mysterious errors.
Sometimes the errors don't show up until after the lisp world has been
saved and restarted.  I must admit that I can't reproduce these problems
on demand.  But to be on the safe side, when I'm making a new saved lisp
with our software loaded in, I start over from scratch if the lisp ever
enters the debugger.  Many of our mysterious problems went away when we
took that approach.

My biggest complaint about the editor and the debugger, and all parts of
system, is that Lucid provides NO source.  Most of the braindamage and
lack of features could easily be fixed if we only had source.  We
haven't had a chance to look into other Common Lisps, but if we find
another one of the same or similar quality that does come with source, I
think we would switch over immediately.

In summary, the Lucid user environment is a toy when compared to the
Symbolics environment.  However, this does have some advantages in that
one does not have to be an expert to use the system.  3600's tend to be
expert friendly.  I would recommend Lucid Lisp for beginners and small
projects.  If you are developping a large system, I would strongly
recommend a 3600 for development and then when necessary porting the
code to Lucid Lisp.  3600's were clearly designed for developping very
large programs, and in my experience no other system comes close.

	    o gc

When the GC turns on, you can't do anything till it finishes.  Just how
long that is depends on the type of machine you're running on and how
large the world is.  A VAX 8800 (we've got a couple of these) takes
about 15-30 seconds.  A Sun 280 is somewhat slower.  I think a Sun 160
is one half the performance of a 280.  A VAX 8300 is about 1/2 the
performance of a Sun 160 (I would recommend against running lisp on an
8300, its unbearable).  

Of course, this also depends on whether the lisp is entirely pagged in.
All our 280's have at least 16Mbytes which seems sufficient for at least
a couple of lisp users (the load on our Sun's isn't very high yet).

Running Lisp from inside GMACS makes the behavior of the GC less
important.  You can go to another editor buffer while the lisp is gc'ing
and return when it is done.  

Obviously, the Symbolics ephemeral GC is a big win.  


	    o major wins/losses vis-a-vis Symbolics

I think the major advantage of a Sun with Lucid Lisp over a 3600 is
price of the hardware.  Most software managers do not appreciate the
difference a 3600 can make in software productivety.  It's can be hard
to justify a $50K system for a 3600 when a $10K (or less per user) Sun
also "runs" Lisp.  Symbolics has got to drop the price of their systems
by a factor of 4.  Maybe TI will do it?

	    o rough estimate of development time vis-a-vis Symbolics

Not a fair question.  This depends entirely upon experience levels.  I
can't really answer this question because I never did any large
development on Lucid Lisp.  All my development was on 3600's.  In fact,
even while porting I used a 3600 continuously because it has
meta-point and edit-callers which lucid doesn't have.



In and of itself, Lucid Lisp is a very good product.  I've heard rumours
that they are working hard on a new user environment.  My comments may
not be valid in few months or whenever they come out with their new
system.


	- Cliff