Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Keywords: resistance to lisp
Message-ID: <11898@well.UUCP>
Date: 30 May 89 04:05:26 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> <1028@syma.sussex.ac.uk>
Reply-To: nagle@well.UUCP (John Nagle)
Lines: 25

In article <1028@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk (Aaron Sloman) writes:
>There is some evidence, albeit based only on a number of cases
>rather than systematic research, that it is much easier to convert
>people to Lisp-like ways of thinking if you give them a Lisp-like
>language (with all the benefits of incremental compilation,
>integrated editor, garbage collector, pattern matcher, lists,
>records, arrays, tuples, etc etc) but not a lisp-like syntax.

      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 or the defunct
LMI machines.  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.  This makes maintenance difficult.  In particular, merging the
work of several programmers is rather painful.  

      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.

					John Nagle