good science and lisp->C case histories

["Robert S. Kirk" <rsk%samson.cadr.dialnet.symbolics.com@RELAY.CS.NET>]

    Date: Mon, 16 Oct 89 16:39:32 PDT
    From: lakin@csli.Stanford.EDU (Fred Lakin)
       Date: Mon, 16 Oct 89 17:18 EDT
       From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
	   Date: Mon, 16 Oct 89 10:44:10 PDT
	   From: lakin@csli.Stanford.EDU (Fred Lakin)
	   I am compiling case histories of large lisp programs that were
	   translated into C.

       To make this good science, you should try to separate the effects
       of rewriting in C from rewriting period.  For example, if a program
       was first written in Lisp, then rewritten in C, and got faster as
       a result, some of the speedup can be attributed to C, some might be
       attributable to faster hardware made accessible by the use of C, and
       some can be attributed to what one learns from rewriting a program.
       I doubt that any controlled experiments have been conducted where
       two teams competed to rewrite a program, one using Lisp and the other
       using C, but the results of such an experiment would certainly be
       interesting.

    I agree completely. Especially, controlling for the "second time you
    write a program effect" would be crucial. Your experiment sounds
    interesting.

    But on the other hand, until there is time and money to do good
    science, I thought it would be interesting to get a list of programs
    that were translated from lisp to C. Certainly one hears on the street
    that such translation is being done all the time (there are only two
    kinds of lisp applications, those already translated into C and those
    that are going to be, etc). So i wondered how much of this is actually
    going on. Of course, any *interpretation* of the cases should be
    subject to the caveats you mention above.

I know of two cases in our company.  One involved a program prototyped
on the Lispm and rewritten into Pascal by another party.  The Lisp
program print out was about 1/8 inch thick.  The Pascal printout was
about 3 inches thick.  I don't really know how much time was involved,
but it seems to me that it took about 3 months to figure out the
algorithm (and its a hairy one, so about 2 months was tied up in
refining some fine points, running test cases, etc.)  I vaguely remember
that the Pascal port took about 6 months (and there were no algorithm
tricks to be figured out!)

Another case involves a language parser/database.  The original version
was written in Pascal and then rewritten 2 more times in Pascal until it
settled down.  The last writting involved 6 people for 4 months,
producing 20K lines of code.  In recent years, this system has been
rewritten in Lisp and about 10 times the number of features and
capabilities have been added (i.e. the equivalent of the old Pascal
program is about 2K lines of Lisp).  Total line count is about 20K lines
Lisp.  About 3 person years have been invested.

When I think about the tradeoffs between Lisp and other languages, it
tends to come down to the issue of how many lines of code a programmer
can write per day.  While there are wide ranges, the average is about 10
lines per day per programmer when working on reasonably large and
complicated programs.  This rate includes designing, implementing,
debugging, documenting, supporting, going to conferences, etc.  (By the
way, in my mind, 20K lines is not very complicated, 100K is.)

If you believe this (many would like to argue it, but its reasonably
accurate) then the fastest way to implement functionality in software is
to choose the highest level language possible.  My experience is that
one line of Lisp equals about 10 lines of Pascal, so there is an
inherent 10x productivity gain.

On the issue of Lisp performance, I have heard lots of grumbling about
Lisp application program performance.  However, our Lisp programmers
easily outpace the `C' programmers in productivity such that our users
prefer to approach the Lisp group for new capabilities, because they
will get much faster response in obtaining new software functionality.
It turns out that our internal need for specials (one time, throw away)
software is getting so large, that the amount of computer time involved
in running "slow" Lisp programs is inconsequential.

       Personally I believe that one ought to use C for what C is good for
       and Lisp for what Lisp is good for, and dispense with the religious
       wars.

    Yes.