Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!apple!netcom!amdcad!dgcad!dg-rtp!sheol!throopw
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Summary: another example of an implementation in LISP and C
Message-ID: <1493@sheol.UUCP>
Date: 24 Mar 91 03:37:40 GMT
References: <602@optima.cs.arizona.edu> <1610006@hpdtczb.HP.COM>
Lines: 59

- wallace@hpdtczb.HP.COM (David Wallace)
>> = David Gudeman
> = Dan Bernstein

>> Programs in dynamically typed languages are generally half to a tenth
>> the size of programs in statically typed languages that do the same thing. 
>I don't believe you. Give an example.

- It's only a single data point, but my first prototype version of ATV (the
- abstract timing verifier I wrote for my dissertation work) was 1600 lines of
- C code.  At that point I changed to Lisp, and got the same functionality in
- less than 300 lines of Common Lisp code.

As another data point (one well-studied one of a cluster of such
I'm familiar with), a configuration management and automated build
program was implemented in about 1000 lines of LISP code, and swelled
to 5000 lines when implemented in C.  The reimplementation was well
studied, because there was controversy over whether any future
tools should be done in LISP.

In this examples, and some other similar but less thoroughly studied
examples of the same controversy, there was essentially no advantage in
terms of the cpu time consumption of this particular application.  There
was, however, a 3-to-1 reduction in memory working set size in favor of
C, as well as a whopping 30-to-1 reduction in memory paged in during
startup of the application in favor of C.  And, of course, the C could
be made available on many more of the platforms we were interested in. 

The studies undertaken at that time showed that the LISP system could be
made more competitive in terms of its memory consumption, especially its
startup thrashing, but the ultimate conclusion was that this wasn't
worth the rather large investment it was estimated to take, at least not
when amortized over the anticipated applications that might be
implemented with the improved system. 

- I also got additional functionality
- for free: command scripts, the next thing I wanted to add to the program,
- took 0 lines of code in Lisp.

This was our experience also (in reverse: that is, we lost a great
deal of flexibility in our command scripts going to C).

But...

As Peter da Silva points out, much of this isn't due to dynamic typing. 
In fact, much of the benefit of the Common Lisp environment as we saw it
was due to the large library of pre-canned functions that are part of
the environment, and the power and generality of the syntax.  Now SOME
of the flexibility and size of the standard available functions can be
attributed to dynamic typing, but MOST of it cannot. 

Note also that much of the DISadvantage of Common Lisp's memory
consumption (both address space and working set) was also NOT due to
dynamic typing, but rather due to run-time evaluation, so that even if
the application code didn't mention (say) complex arithmetic, it
couldn't be assumed that a runtime evaluation of a text string wouldn't
involve it. 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw