From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: handling parenthesis and quotes Date: Sat, 27 Jan 2007 13:20:19 +1100 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <87lkjp5hy4.fsf@lion.rapttech.com.au> References: <878xftpinw.fsf@kobe.laptop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1169865640 17806 80.91.229.12 (27 Jan 2007 02:40:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 27 Jan 2007 02:40:40 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 27 03:40:34 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HAdUW-0006Tf-TW for geh-help-gnu-emacs@m.gmane.org; Sat, 27 Jan 2007 03:40:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HAdUW-0002qI-CN for geh-help-gnu-emacs@m.gmane.org; Fri, 26 Jan 2007 21:40:32 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!feeder.news-service.com!138.199.65.86.MISMATCH!sn-xt-ams-06!sn-xt-ams-03!sn-ams!sn-feed-ams-02!sn-ams!sn-feed-ams-01!sn-post-ams-01!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux) Cancel-Lock: sha1:vIDbNKO1MtsnujJ9K041LZTJo+w= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 52 Original-Xref: shelby.stanford.edu gnu.emacs.help:145093 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:40697 Archived-At: Harald Hanche-Olsen writes: > + Adam : > > | 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