In article <···@arisia.Xerox.COM> Ronald A. Fischer writes about
considering Lisp development environments when comparing/benchmarking different
Lisp systems.
>Consider how much shorter your development time
>might be with a better set of development tools or application
>toolkit.
While I have never worked with ENVOS I did spend 4 years doing product
development in InterLisp on Xerox D machines - the environment sounds
identical. I can not overemphasize how valuable the development
environment was to the development effort. These tools included the structure
editor DEDIT, the object inspector, the D window system, the debugger
package, SPY, MASTERSCOPE, CLISP, DWIM, LOOPS, etc, etc.
The environment really helped to reduce development time and it allowed people
to do rapid prototyping e.g. make massive exploratory code changes quickly.
( Refer to "Power Tools for Programmers" (?) by Beau Sheils
onetime president of Xerox AIS (?). This magazine article describes
the benefits of a rich development environment i.e. the D machine.
It has appeared in _Datamation_ and several books on programming environments
and user interfaces. )
I have since done product development in VAXLisp under VMS and Ultrix,
PSL under Ultrix, and Golden Common Lisp under MS-DOS.
They produce very fast code but when I last used them they had
just about NIL in the way of development tools - vi/edt/emacs and what
was called a "debugger".
When moving to these Lisps it seemed that the first thing developers
who were familiar with D machines or Symbolics boxes did
was to write some basic tools that were missing in
these environments (extensions to the debugger, xref utilities,
performance timing utilities, a file package manager, etc). Not what you
wanted to do when faced with deadlines.
Project development slowed considerably due to the effort put into
developing and maintaining the support tools as well as the relative
lack of a supportive development environment.
The environment IS the Lisp at least for development. In the best of
worlds you would do development on your D machine equivalent and then
port the finished code to your "fast" production machine.
>I've also not touched on the basic problem that many highly optimized
>Lisps will now produce "unsafe" code, i.e. it will crash your Lisp
>image or worse operating system if simple errors occur. This has...
This makes debugging extremely difficult. I have worked
with "fast" Lisps that have had this problem. At one time a popular MS-DOS
Lisp had a compiler bug that would produce code that
trashed memory and initiated a perpetual GC. It took weeks
to find the cause, and weeks to convince the vendor that there was a
problem and get a patch. This all happened a few months before the product
was to be shipped!
A nostalgia for my old 1108 and that wonderful software from Xerox
Parc has prompted this message. I now code in C on Unix systems - surely
the Goths have invaded the temple...
P.S Anyone from Bachman or Apex out there? Drop me a line.
Jesse "It could be worse - It could be DOS" Thorn
North Carolina Memorial Hospital
Chapel Hill, NC
UUCP: ...!mcnc!godot!thorn,
INTERNET: ·····@godot.radonc.unc.edu
The comments made regarding the sparseness of non-lispm development
environments could have come from any of those of us in my group here at Los
Alamos who in the last couple of years have switched from Symbolics' to
Suns and Lucid lisp.
We _REALLY_ missed the frame-based debugger & inspector, as well as
the powerfull ZMACS editor. While Lucid 3.0 is an improvement over 2.1
it still has a long way to go before the development environment will
compare to a Symbolics. The editor has greatly improved in 3.0, but
the inspector and debugger still reek of the early 70's :-(...
The sad fact is that most current-day lisp programmers have never
worked on a lispm, and so they don't know what they're missing.
--Doug
--
===============================================================
Douglas Roberts
Los Alamos National Laboratory
Box 1663, MS F-602
Los Alamos, New Mexico 87545
(505)667-4569
····@lanl.gov
===============================================================