From: John W. Dye Jr.
Subject: Unix Lisp Environments (why the slow evolution)
Date:
Message-ID: <7802@zodiac.UUCP>
On the subject of Lisp Environments for Unix (SUN) workstations.
As a former Lispm user who presently is a Sun common-lisp hacker
I would like to make a few observations about the state and
evolution of lisp environments for Unix workstations. Hopefully
these comments will spark constructive discussion about what
we can do to speed the arrival of good lisp based programming environments.
1) There is not much of a market for Lisp based products (compared to
C or (UGH) Fortran). This is the reason that companies cannot afford
to devote amazing amounts of resources to bring lisp based programming
environments to market.
2) The window systems keep changing. First there was sunview. Then there
were X and NeWS. Now there is (soon) a NeWS/X merge (with suntools
support also). Developers of lisp programming environments have had
to program on a moving target (the window systems). Unfortunately,
most of the neat stuff that lisp programming environments do are
window based (window-debuggers, fancy editors).
3) Finally, Emacs isnt that bad. It's programmable, and with the
right set of hacks and tags tables it begins to approximate the
typical symbolics compile-test-debug cycle that we are all so
familiar with.
The biggest problem we still face is debugging a multiprocessing lisp
using emacs only (we dont like sunview--OK!). It would be nice to have
a facility like the lucid editor provides in good old gnu emacs.
What can we do about it???
We could all get together and agree on a window-system platform and
then build the gnu-lisp environment out of it!!
We can wait for Sun,Lucid,Franz, etc to supply us with one
(see point 1).
Any other Ideas???
JD
····@ads.com
"ADS didn't make me write this--STD Disclaimer."
P.S. I am encouraged by the state of Lisp and its direction. I forsee
people actually delivering software that runs in lisp in the next 3-5
years.
In article <····@zodiac.UUCP> ····@zodiac.ADS.COM (John W. Dye Jr.) writes:
>
> On the subject of Lisp Environments for Unix (SUN) workstations.
>
> As a former Lispm user who presently is a Sun common-lisp hacker
> I would like to make a few observations about the state and
> evolution of lisp environments for Unix workstations. Hopefully
> these comments will spark constructive discussion about what
> we can do to speed the arrival of good lisp based programming environments.
>
> 1) There is not much of a market for Lisp based products (compared to
> C or (UGH) Fortran). This is the reason that companies cannot afford
> to devote amazing amounts of resources to bring lisp based programming
> environments to market.
>
> 2) The window systems keep changing. First there was sunview. Then there
> were X and NeWS. Now there is (soon) a NeWS/X merge (with suntools
> support also). Developers of lisp programming environments have had
> to program on a moving target (the window systems). Unfortunately,
> most of the neat stuff that lisp programming environments do are
> window based (window-debuggers, fancy editors).
>
> 3) Finally, Emacs isnt that bad. It's programmable, and with the
> right set of hacks and tags tables it begins to approximate the
> typical symbolics compile-test-debug cycle that we are all so
> familiar with.
>
>
> The biggest problem we still face is debugging a multiprocessing lisp
> using emacs only (we dont like sunview--OK!). It would be nice to have
> a facility like the lucid editor provides in good old gnu emacs.
>
> What can we do about it???
>
> We could all get together and agree on a window-system platform and
> then build the gnu-lisp environment out of it!!
>
> We can wait for Sun,Lucid,Franz, etc to supply us with one
> (see point 1).
>
> P.S. I am encouraged by the state of Lisp and its direction. I forsee
> people actually delivering software that runs in lisp in the next 3-5
> years.
>
You make some good points, especially the one regarding the small
market share of LISP. I think, however, that you missed one of the
major reasons that the Unix LISP environment is still decidedly
inferior to a LISPm: the majority of the market that is considering
LISP as a language in which to deliver applications is currently a
member of either the Unix or the VMS community: _they are not aware of
the productivity that exists ion a LISPm_. Nor _will_ most of them
become aware, given the cost disparity between LISPm hardware and the
other workstations.
What can we do about it? Complain, for one thing. I know that the
major vendors listen to this forum (over the past two years I've
received feedback from a number of the major software and hardware
vendors to comments made here). I believe that some fruit has already
been born, in part because of comments made to this list. Assisting to
the extent possible in establishing a standard window system will also
help, of course.
Regarding your P.S., we have been delivering LISP applications to our
customers for two years now.
--Doug
--
===============================================================
Douglas Roberts
Los Alamos National Laboratory
Box 1663, MS F-602
Los Alamos, New Mexico 87545
(505)667-4569
····@lanl.gov
===============================================================
From: Dan Weinreb
Subject: Re: Unix Lisp Environments (why the slow evolution)
Date:
Message-ID: <352@odi.ODI.COM>
In article <···@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
Indeed, I think it is often easier to develop tools for languages,
such as C, that are more straightforwardly based on files, statements,
and lines of code. On Suns, for example, dbxtool can get some very
useful effects simple by displaying the relevant lines of a source
file. Most Lisp debuggers find it very difficult to relate evaluation
to source code, and this is perhaps a greater problem in Common Lisp
because so much tends to be done by macros. Macro expansions often
look very little like what the user wrote. This can be true in C as
well, but most of the time it doesn't matter, because the debugger
works with lines of source rather than with individual expressions.
Yes, the reason it's hard in Lisp is entirely due to macros. Look at
the Symbolics debugger: when it is operating on C, Fortran, or Pascal
code, it works completely correctly with the original source code (and
works a whole lot better than dbxtool, by the way). But doing the
same for Lisp is significantly harder, because Lisp macros are so
powerful. It's a tradeoff: it is harder to write a source-level
debugging for an extensible language like Lisp than for a fixed
language like C. Of course, Lisp's extensibility (arising from
macros) is one of the biggest advantages of the Lisp language. C
macros are much wimpier, and therefore easier to deal with. Still,
the fact that the C debuggers cannot handle macros can be a true pain
in the neck, as I've discovered in practice.
In article <···@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
> In article <····················@studguppy.lanl.gov> ·······@studguppy.lanl.gov (Doug Roberts) writes:
> I think, however, that you missed one of the major reasons that the
> Unix LISP environment is still decidedly inferior to a LISPm: the
> majority of the market that is considering LISP as a language in which
> to deliver applications is currently a member of either the Unix or
> the VMS community: _they are not aware of the productivity that exists
> on a LISPm_.
>
> I think you have identified an important point. However, I would
> guess that most of the people who implement Lisps for Unix (Lucid,
> Franz Inc, at al) do have a fairly good idea of what the Lisp Machines
> accomplish. So why don't they provide the same thing on conventional
> machines?
>
> I think it's possible to provide environments that are very similar.
> People here who use Inference ART (Automated Reasoning Tool, or
> something like that), which is built on top of Lisp, report that the
> ART environment on a Sun is very close to that on a Symbolics,
> although at the Lisp level the debugger probably isn't as good.
>
> However, possible is not the same as easy, and I suspect the Lisp
> implementors have not had sufficient resources to let them prepare
> environmental tools as soon as they'd have liked.
>
During my visit to Lucid a few months ago, I got the impression that
many (but not all) of the internals people there had a previous
history with LispMs. I did receive an interesting comment to my
suggestion that they should try to emulate the functionality of
Symbolics' window debugger in their lisp environment. The comment was
something like" "Groan... Just what we need... To make our product
more Symbolics-like."
I suspect that the Unix lisp developers' priorities regarding
development environments are changing. After one of my previous
postings in which I complained about the lack of good debuggers &
inspectors, I received mail form Lucid and Ibuki, and phone calls from
Franz and Envos. Ibuki, Franz, and Envos all offered their products as
examples of "new, improved" more functional development lisp
environments. I haven't heard directly from Lucid regarding any
efforts they might have on-going, but I did read in a previous posting
from this group about a "Cadillac" environment that they are working
on?? I also don't know what Sun might be working on, if anything (Sun
of SPE? :-})..
On that note...
--Doug
--
===============================================================
Douglas Roberts
Los Alamos National Laboratory
Box 1663, MS F-602
Los Alamos, New Mexico 87545
(505)667-4569
····@lanl.gov
===============================================================