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