Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!m2c!jjmhome!smds!rh
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <359@smds.UUCP>
Date: 27 Mar 91 03:48:52 GMT
References: <602@optima.cs.arizona.edu> <1610006@hpdtczb.HP.COM> <1493@sheol.UUCP>
Organization: SMDS Inc., Concord, MA
Lines: 71

In article <1493@sheol.UUCP>, throopw@sheol.UUCP (Wayne Throop) writes:

> 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...

> 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. 

Just another data point.

We developed Lakota internally as a scripting language and have found
rather similar results.  For example, a 500 NCL C program was replaced
by a 35 NCL Lakota program.  An approoximate breakdown for the reasons
for reduction in code size is:

	15%	Elimination of declarations
	35%	Use of intrinsic language functions
	20%	Dynamic list operations
	20%	Free form string concatenation

To the point of this particular discussion -- Lakota is an untyped
language.  (More precisely, it has a single type, lists of strings;
types, if needed, are implemented as ADT packages; numeric operations
are recognized in functional context.)  Some points that may be relevant:

(a)	One of the features that reduced code size and made for increased
readibility was the elimination of the need for lots of "helper" variables,
i.e. loop indices, auxiliary arrays, variables containing sizes and
counts, etc.  I rather suspect that the same would be true for the cited
lisp program.  Much of this can be attributed to intrinsic dynamic data
structures.  Calculation of sizes, allocation of storage, and variable
"declarations" are handled by the language processor rather than by the
programmer.

(b)	Intrinsic functions such as sorting and splitting strings into
a list of fields played a major role in reducing size.  There are several
factors here.  (1) The ability of function operators to act on and return
lists, (2) consistent syntax which makes composition of operators convenient,
and (3) the elimination of "set-up" operations, i.e. allocation,
initialization, etc.  The fundamental gain over C (even given the
availibility  of equivalent library routines) is in the smoothness of
the interface between operations.

Speed:  Lakota is an intrinisically interpreted language.  On the whole
the execution times are 2-5 times slower than the equivalent C programs.
[The intended usage is high-level administrative with compute intensive
grunt work being done by 3GL subroutines and programs; ergo execution
time is not a penalty factor.]  Development time of Lakota vs C (or
equivalent 3GL) is at least an order of magnitude faster -- the salient
points are reduced code size, reduced syntax errors, elimination of the
compile and link step, and the ability to execute individual routines
in standalone mode.

A final note.  In the context of this discussion Lakota is not
execeptional; smaller code size, sharply reduced development time,
dynamic data structures, and functional composition are features of
many of the other languages mentioned.  I used Lakota as an example
because I am working with it at the moment.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.