Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpcc05!hpsciz!hpdtczb!wallace
From: wallace@hpdtczb.HP.COM (David Wallace)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <1610007@hpdtczb.HP.COM>
Date: 25 Mar 91 23:17:02 GMT
References: <602@optima.cs.arizona.edu>
Organization: HP Design Tech Center - Santa Clara, CA
Lines: 67

> peter@ficc.ferranti.com (Peter da Silva) 
>> Me

>> 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.  (load "file") worked just fine.
>
>Forth is a statically "typed" language, and has the same advantage. This
>has nothing to do with dynamic typing.

Agreed.  I was supplying information about the one example I have
hard data on, not arguing that all the difference was due to static vs.
dynamic typing.  This wasn't a controlled experiment in which only
one independent variable was changed, it's a historical anecdote that
happens to meet the basic conditions David G. was describing (basically
the same program in a dynamic vs. a statically typed language).

My comment above was intended to clarify the degree to which
the two programs had the same functionality: they did, in that all the code
I re-wrote in Lisp was intended to replicate the existing functionality of
the C version, but they also didn't, because I was able to add this new
functionality to the Lisp version without writing any new code.
If I had added command scripts to the C version also, we would have had
two functionally equivalent comparisons: 1600:300 for the comparison without
command scripts, and (1600+X):300 for the comparison with them.

Obligatory caveats: this is the one example I happened to have data for.
It is consistent with David Gudeman's assertion.  It does not prove it, though
it does add to the credibility of the assertion for me.  Two potential
sources of bias are:

	1) This was early prototype code.  As such, both versions lacked the
	extensive error checking and recovery typical of more bulletproof
	production code.  I do not know what the ratio of code size in such
	code would be.  I suspect it would still favor Lisp (some errors just
	don't happen in Common Lisp, such as integer overflow), but the ratio
	could very well be more even.  (Note though that the reason for CL not
	having integer overflow is because CL exploits dynamic typing to give
	you automatic bignums as needed.)

	2) I re-wrote the code in Lisp because I felt it would be easier to
	develop this particular program in Lisp than in C.  The data suggests
	that I was right.  The same results would not necessarily hold for
	applications that were more naturally oriented towards C than Lisp.

	In particular, there were chunks of the initial C code that were
	devoted to list manipulation, storage management, and input parsing,
	each of which became much simpler or a non-issue in Lisp.  None of
	these are directly a result of dynamic typing, but they all tend
	to be at least weakly related (e.g., tagged storage supports both
	dynamic typing and garbage collection, so the two tend to go together;
	garbage collection in turn helps support many of the Lisp list
	manipulation functions; and polymorphic read functions (supported by
	dynamic typing) facilitate input parsing).  In any case, David's
	specific assertion was about programs in dynamically typed languages
	(with all the baggage that goes along with them), not about the
	effects of dynamic typing in isolation.

In summary: David Gudeman asserted that programs written in dynamically typed
languages were generally half to a tenth the size of equivalent programs
in statically typed languages.
Dan Bernstein questioned the assertion and asked for an example.
I supplied the data from the one non-trivial example I have known where
a direct comparison was possible, and noted that the data was consistent
with David's assertion.

Dave W.		(wallace@hpdtl.ctgsc.hp.com)