Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <1021@optima.cs.arizona.edu>
Date: 22 Mar 91 15:05:56 GMT
Sender: news@cs.arizona.edu
Lines: 60

In article  <1991Mar20.185308.8275@maths.nott.ac.uk> Dr A. N. Walker writes:
]
]	Have you actually *read* the Algol 58 (or IAL) report?

I don't recall.  Not in a long time if ever.

]  The Algol
]tradition is of a patrician disregard for efficiency, which argues against
]your assertions that various features were put in to make code generation
]easier.

I'll bet though that what you consider a patrician disregard for
efficiency I will see as a psychotic fixation on same.

]  As late as Algol 68, the arguments are mostly about whether
]things can, *in principle*, be compiled;

Yep, psychotic fixation on efficiency.  They weren't arguing on
whether something could be _implemented_, they were worried about
producing machine code.  Meanwhile the lisp people were happily
implementing things without worrying how fast they would run.

]	Certainly.  On the other hand, if writing out each identifier
]that you use just once extra, with [usually] one word and a semicolon,

No, that is not the problem with static typing.  It is not uncommon to
have to declare variables in dynamically typed languages, you just
don't specify the type.  When I complain about too many declarations,
I'm not talking about declaring simple variables, I'm talking about
the large detailed declarations needed to create any data structure
with even moderate complexity.  I believe that these declarations are
responsible for an inordinately large percentage of the errors in
programs.

Another problem is that static type declarations usually require the
programmer to over-specify the solution.  This is a problem for
initial developement, maintenance, and code re-usability.  In initial
developement, it is not uncommon to get continuous requirements
changes and these are easier to deal with if fewer details have been
engraved in code.  Similar comments apply to maintenance.

Dan mentions that the power of a language is related to the amount of
re-usable code written in the language, but that is an incomplete
observation.  There is also the question of how much a language
encourages the writing of re-usable code.  In statically typed
languages it is always more difficult to write a generic package than
a special-purpose package.  The difference in difficulty varies a
little over languages, but the fact remains that if it is _any_ more
difficult to write re-usable code, less re-usable code will be
written.  In dynamically typed languages it is just as easy to produce
re-usable code as not.  In fact it takes some imagination to make code
not re-usable.

Ironically, those programing features that are intended to make it
more possible to write re-usable code tend to lead to more voluminuous
declarations, thereby making the error problem worse.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman