Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!cme!cam!miller
From: miller@cam.nist.gov (Bruce Miller)
Newsgroups: comp.lang.lisp
Subject: Re: Software Productivity Using Lisp
Summary: more to it
Message-ID: <1257@kar.cam.nist.gov>
Date: 4 Oct 89 00:00:43 GMT
References: <5896@lifia.imag.fr> <865@skye.ed.ac.uk> <2084@munnari.oz.au> <11297@eerie.acsu.Buffalo.EDU>
Organization: National Institute of Standards & Technology, Gaithersburg, MD
Lines: 36

In article <11297@eerie.acsu.Buffalo.EDU>, summers@gort.cs.buffalo.edu (Michael Summers) writes:
> 
> Does anyone have any data on lisp programmer productivity
> ...
> this. My guess is that this is due to,
> 
>    1) The number of  useful high level functions ..
> 
>    2) The time saved debugging the code through the use of
> the symbolics debugger and interactive environment.
> 
Well, I know you wanted data rather than discussion, but your guess kind
of invites discussion.
Your two points start to cover it, but for me, personally, there is much more
to 2) than meets the eye.  

The lisp-as-data quality in some (mystical? :)) way greatly extends what
the `interactive environment' ends up providing;
besides of course the power of having REAL macros, and never mind functions 
writing functions (other than macros, of course!).

I can (sometimes) whip through coding because I can test out each function as
I write it. Well, thats just `interactive environment.' But, in Lisp you can
do  much more thorough testing at the extremes because you can relatively 
easily cook whatever extreme data it needs to be tested with.

As far as macros are concerned, conceding that I'm not an ace C programmer,
It is always extremely painful for me to set up in C an `environment' in
which to execute some code.  Perhaps `environment' is just not a C way of
thinking? :)

Well, I guess I'm not terribly lucid today, I hope that makes (non-trivial) 
sense...

Bruce
miller@cam.nist.gov