From: ···········@gmail.com
Subject: Lisp Development Process
Date: 
Message-ID: <1181556013.511172.64490@i38g2000prf.googlegroups.com>
I've found one of the most exhilarating features of Lisp is its
ability to play around with it as its running, among its many other
fun features. But because this idea is so core to Lisp, I wanted to
ask the developers who've used Lisp for large projects -- how does
this change around your development process? What would you do
differently from the process you use when working with a compile-run-
debug process?
From: ·····@evins.net
Subject: Re: Lisp Development Process
Date: 
Message-ID: <1181659534.776134.285230@o11g2000prd.googlegroups.com>
On Jun 11, 4:00 am, ···········@gmail.com wrote:
> I've found one of the most exhilarating features ofLispis its
> ability to play around with it as its running, among its many other
> fun features. But because this idea is so core toLisp, I wanted to
> ask the developers who've usedLispfor large projects -- how does
> this change around yourdevelopmentprocess? What would you do
> differently from theprocessyou use when working with a compile-run-
> debugprocess?

On the plus side, the distance between conceiving something and
testing it running is much shorter in an interactice environment like
a typical Lisp. It's not unusual to write a function that calls two
functions that don't yet exist, then run it. Of course, the Lisp then
signals an error and enters a break loop, but you can just define the
undefined function that it broke on, and continue. Some folks
sometimes implement whole subsystems incrementally like this.

Or you can work bottom-up, starting with some primitives you know you
are going to need, defining them and testing them interactively,
because they are available to you essentially as soon as you type them
in. You can then write higher-level functions that compose them, build
test data interactively and immediately see what happens when you pass
them to your functions.

It's a fast way to work, and you can get real results without even
necessarily knowing what all the parts of your system are.

On the minus side, you do need to remember that your code is running
in an environment where you may have monkeyed quite a bit with a bunch
of state. In the traditional edit-compile-run scenario, the program's
world is new and fresh each time you run it. That's not necessarily
true in a Lisp environment, where you may have built and modified some
assortment of data structures, and the code you are running read or
write them. Bugs can arise because, for example, one of your functions
is using a value that exists only because you put it there by hand a
couple hours ago, and you've forgotten that detail. That's not a show-
stopper or anything; you just have to remember that you are monkeying
around with your program's runtime environment, and take suitable
precautions. For example, you might build tests that you run only in a
freshly-launched environment.