summers@gort.cs.buffalo.edu (Michael Summers) (10/04/89)
Does anyone have any data on lisp programmer productivity using various software development environments? I am particularly interested in SW productivity in environments with strong symbolic debuggers such as GENERA, SUN's SPE and TI's systems. I am interested in any sort of hard data. I realize that I may get a lot of responses discussing, how hard it is to quantify SW productivity, how it really depends on what you are doing and on the programers abilities, how lines of code estimates are meaningless etc. What I really would like is any sort of real data with as much background information as possible. Comparisions between the number of lines of code needed to produce simular functions when working in your favorite lisp environment vs other languages environments would be appreciated. Also any sort of estimate on the number of lines of code produced per day would be helpful. I hear SW engineers use figures like 8 to 12 lines of debugged code a day. My gut feeling is that a good lisp programer working in an advanced environment with a good debugger, inspector, etc. should be an order of magnitude more productive than this. My guess is that this is due to, 1) The number of useful high level functions in languages like CL and the various machine specific extensions like SCL that save time over coding in "C" for example. 2) The time saved debugging the code through the use of the symbolics debugger and interactive environment. I once listened to a talk by a representative of a lisp machine vendor who said that their system was designed to make code production cheap and thus to make rapid prototying an economic reality. Does the community verify this?
miller@cam.nist.gov (Bruce Miller) (10/04/89)
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
jacob@ait.trl.oz (Jacob Cybulski) (10/06/89)
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. > Again, rather than qualitative data, I have only got gut feelings for you. To me LISP provides a nice, consistent, clean conceptual environment. It is not the number of useful high level functions that make LISP attractive, I even prefer Scheme of which early versions were not as rich in functions as CommonLISP; it is not interactive debuggers, editors, tracers, steppers, and the like which make LISP a superb language. It is a neat syntax and overall conceptual integrity which makes LISP a great productivity tool. Programming in LISP is comparable to THINKING. I find PROLOG in the same class of cognitive tools as LISP, although I feel more efficient with LISP. Jacob L. Cybulski Mail: Artificial Intelligence Systems Telecom Research Laboratories 770 Blackburn Road Clayton Victoria 3168 Australia Phone: +613 541 6273 Fax: +613 543 8863 ACSNet: jacob@trlamct.trl.oz ARPA: jacob%trlamct.trl.oz.au@uunet.uu.net UUCP: ...!uunet!murtoa.cs.mu.oz!trlamct.trl.oz!jacob o | o Jacob L. Cybulski \_/ Artificial Intelligence Systems Telecom Research Laboratories