Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Keywords: resistance to lisp
Message-ID: <497@skye.ed.ac.uk>
Date: 31 May 89 15:25:39 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> <1028@syma.sussex.ac.uk> <11898@well.UUCP>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 68

In article <11898@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>       I've found LISP as a language quite useful over the years, but
> the "integrated environments" are something of a pain.  It's not at
> all clear that the development environment and the object being developed
> should be as intertwined as they are on, say, a Symbolics ...

Interestingly enough, some people have exactly the opposite view.
They think that programmers don't really like Lisp as a language --
what they really like is the environment.  I have even heard this
said to students by the person teaching them Lisp.

There are also some people who would like to give Prolog an
"environment like Lisp".  This is a less extreme view, but it
also presupposes that Lisp and it's environment can easily be
separated.

> What seems to happen in these systems is that the developed
> object is a world, that is, a copy of the entire environment, rather than
> a source text.  The state of the system becomes part of the thing being
> developed.

The Symbolics and LMI environments do let you write a set of files.
And, indeed, that's where function definitions are kept.  The Xerox
approach is more intertwined, because you don't operate directly on
the files.  You build a world, and then the system tries to write
all of the files for you.

However, whenever you do interactive development it seems to be
possible to have some things work only because files happened to be
loaded in a certain order, and then some computations were done, then
some functions refefined, etc. so that just relaoding the files won't
give you a working system.

But this hardly shows that noninteractive development is better.
And it doesn't mean that your intent can't be to develop a source
text.

> This makes maintenance difficult.  In particular, merging the
> work of several programmers is rather painful.  

I would say that the Lisp environment can be considered something
like dbxtool for C.  Why is it a bad thing if I can change one function
and continue rather than having to recompile, relink, and start over?
That is, I don't think I have to use a Lisp machine to build a world.
It can be used just to write a program.

And, since I don't see how dbxtool makes it harder for programmers
to work together, I don't see why the LispM environment has to do
that either.

>       The Symbolics approach seems to be oriented toward the classic
> hacker-type approach to programming.  The AI community sometimes calls
> this "exploratory programming", although that term is somewhat in 
> disrepute today.  It does not seem to be oriented toward the development
> of programs that will be used by others.

The idea was always in dispute (and so, I guess, in disrepute to
those who didn't like it).  There have long been people (Dijkstra
comes to mind) who think it best to think, write things out on
paper, and even prove them correct, before typing them in.  But
is this always the best way to proceed?

Moreover,if I'm going to write something down, I'd just as soon type
it in.  And if it's typed in, I'd like to test it out.  But, in any
case, just because something is good for exploratory programming
doesn't mean it's no good for anything else.

-- Jeff