Re: handling parenthesis and quotes

[Tim X <timx@nospam.dev.null>]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> + Adam <nospam@example.com>:
>
> | A related newbie question might be, is this the 
> | usual approach for 'incremental programming' by 
> | Lisp users ?  That is; write a function, 
> | then append that function to a file of work 
> | with append-to-file ?  
>
> I don't know what most people do.  Incremental programming is more
> about ways to build a program than about particular editing habits, I
> think.
>
> It is all about building your application bit by bit, testing as you
> go, and basing your work on what went before - and occassionally going
> back and redoing things when you discover that design mistakes become
> a hindrance to further work.  How people save and organize their work
> is probably highly individual, but appending new functions willy-nilly
> to a file seems too disorganized for my taste.  Rather, I work on the
> program files themselves, trying to keep related functions
> together. And whenever I have written a new function or rewritten an
> old one, I evaluate the defun directly from the buffer (using C-M-x).
> Then I use the interaction buffer mainly to test my work.
> The same method works for Common Lisp using slime.  And since slime
> has facilities for making this style of work easy, I suspect something
> like it is a popular method.  8-)
>

This is basically the way I work as well and most people I've spoken to or
worked with on projects in elisp, CL and scheme do it this way - in fact, any
language where you have some sort of REPL. Its a nice way to work as you see
results quite quickly and don't spend time sitting around for slow makes to
complete before you can see if your small bug fix worked. 

I do tent to have an elisp working file which contains functions etc that I've
been working on that are not yet part of a bigger, more defined project.
However, often I find that my initial function spawns more functions as I
break up my code and begin to understand the problem better, so eventually, I
usually end up with related functions in a file or library. 

One aspect of working this way I really like is that the programming is more
exploratory than with other languages like C or Java. In these languages, you
(I) tend to spend a fair amount of time up front designing the system and then
coding it. IN lisp dialects, I often start with only a fairly vague idea of
what I want and the program sort of emerges from that initially vague
definition through exploration. I can't say which method works better, but I
certainly find the exploratory approach more rewarding intellectually. 

Tim

tcross (at) rapttech dot com dot au