leff@smu.UUCP (11/26/83)
#N:smu:10900002:000:689 smu!leff Nov 24 17:38:00 1983 Is anybody aware of study's on productivity studies for lisp. 1. Can lisp programmers program in lisp at the same number of lines per day,week,month as in 'regular' languages like pascal, pl/1, etc. 2. Has anybody tried to write a fairly large program that normally would be done in lisp in a regular language and compared the number of lines ratio. In APL, a letter to Comm. ACM reported that APL programs took one fifth the number of lines as equivalent programs in regular language and took about twice as long per line to debug. Thus APL improved the productivity to get a function done by about a factor of two. I am curious if anything similar has been done for lisp.
franka@tekcad.UUCP (11/28/83)
#R:smu:10900002:tekcad:3600002:000:799
tekcad!franka Nov 27 13:57:00 1983
I don't have any documentation, but I heard once from an attendee
at a workshop on design automation that someone had reported a 5:1 productivity
improvement in LISP vs. C, PASCAL, etc. From personal experience I know this
to be true, also. I once wrote a game program in LISP in two days. I later
spent two weeks debugging the same game in a C version (I estimated another
factor of 4 for a FORTRAN version). The nice thing about LISP is not that
the amount of code written is less (although it is, usually by a factor of
2 to 3), but that its environment (even in the scrungy LISPs) is much easier
to debug and modify code in.
From the truly menacing,
/- -\ but usually underestimated,
<-> Frank Adrian
(tektronix!tekcad!franka)marcel@uiucdcs.UUCP (11/30/83)
#R:smu:10900002:uiucdcs:32300010:000:740 uiucdcs!marcel Nov 29 19:04:00 1983 And now a plug from the logic programming people: try prolog for easy debugging. Though it may take a while to get used to its modus operandi, it has one advantage that is shared by no other language I know of: rule-based computing with a clean formalism. Not to mention the ease of implementing concepts such as "for all X satisfying P(X) do ...". The end of cumbersome array traversals and difficult boolean conditions! Well, almost. Not to mention free pattern matching. And I wager that the programs will be even shorter in Prolog, primarily because of these considerations. I have written 100-line Prolog programs which were previously coded as Pascal programs of 2000 lines. Sorry, I just couldn't resist the chance to be obnoxious.
Anonymous@uicsl.UUCP (12/01/83)
#R:smu:10900002:uicsl:15500018:000:683 uicsl!Anonymous Nov 30 10:25:00 1983 The most incredible programming environment I have worked with to date is that of InterLisp. The graphics-based trace and break packages on Xerox's InterLisp-D (not to mention the Lisp editor, file package, and the programmer's assistant) is, to say the least, addictive. Ease of debugging has been combined with power to yield an environment in which program development/debugging is easy, fast and productive. I think other languages have a long way to go before someone develops comparable environments for them. Of course, part of this is due to the language (i.e., Lisp) itself, since programs written in Lisp tend to be easy to conceptualize and write, short, and readable.
tjt@kobold.UUCP (T.J.Teixeira) (12/02/83)
I agree that the Lisp programming environment (i.e. support tools) is
responsible for making Lisp highly productive, along with being an
interpreted language and providing automatic storage management (i.e.
garbage collection). At the same time, production Lisp's have avoided
being mere toys by providing good compilers so that the interpreter is
mainly used as a debugging aid for large programs.
I can only think of two features of the language itself that explain
why Lisp is the only major language supporting this type of programming
environment:
1) Data types are associated with values, not variables, and are
determined at run time. Without an interpretive environment, this
is a bad idea (consider all the trouble you can get into in typeless
languages such as assembly language or BCPL), and it is definitely
worth while to include type declarations that can be checked at
compile time. Using an interpreter (and incremental compiler) makes
it very much cheaper to correct this type of mistake.
2) There is a unique, simple and obvious way of representing programs
as data. I don't think the advantage is so much that Lisp is easy
to parse (the reason that is usually expounded), but rather that the
parse trees are easy to manipulate. For most other languages, if
you have n different independently developed compilers, you will
have as many different internal representations of parse trees.
This makes it extremely difficult to build on previous work.
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200Kandt.pasa@PARC-MAXC.ARPA (12/13/83)
Jonathan Slocum (University of Texas at Austin) has a large natural language translation program (thousands of lines of Interlisp) that was originally in Fortran. The compression that he got was 16.7:1. Also, I once wrote a primitive production rule system in both Pascal and Maclisp. The Pascal version was over 2000 lines of code and the Lisp version was about 200 or so. The Pascal version also was not as powerful as the Lisp version because of Pascal's strong data typing and dynamic allocation scheme. -- Kirk