Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!shlump.nac.dec.com!decuac!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc
Subject: RE: Dynamic typing (part 3)
Message-ID: <16MAR91.11493168@uc780.umd.edu>
Date: 16 Mar 91 11:49:31 GMT
References: <602@optima.cs.arizona.edu> <2400034@otter.hpl.hp.com>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 47
Nntp-Posting-Host: uc780.umd.edu

Steve Knight writes:
 ... (ML examples ommitted) ...
>My belief is that, to date, there's been no programming languages that 
>gives the obvious benefits of strong typing without some significant penalty.
>The penalty is typically both superfluous type-declarations in the program
>and the elimination of valuable programming idioms.  (Furthermore, the issue
>of performance is greatly complicated by the elimination of these idioms.)
> 
>Unsurprisingly, I am inclined to believe that strong Vs dynamic
>typing is an unresolved debate.  In practical terms, it is still horses for
>courses.  When writing low-level code, strong typing is (in my view)
>invaluable.  When writing in "very" high-level languages, such as Lisp or
>ML, the penalties are less tolerable (in my view) and, on balance, I prefer
>dynamically typing.

Well, yess.. 

Since you didn't define what you meant by Strong and Dynamic typing,
and since I don't think those definitions conflict in the way they
have been used in this subject thread, well... hmm...

If you say strong typing is what you presented in the ML examples,
what would you say dynamic typing is?

Also, I believe that some of the 'limitations' of ML are tolerable.
For example, I don't compare functions, I compare their character
representations (not that I need much of that, except for library
maintainence).  Also, I almost always live with homogenous data
structures (all elements of the same type)--there are a lot of
performance advantages to this (e.g. 10000 elements need only one type
header, which only need be checked once per pass over the data).

Finally, though this is somewhat of a self-imposed limitation, I 
don't use a lot of the facilities that are available, unless
absolutely necessary (in other words, since the primitives will
already deal nicely with those 10000 numbers, or whatever, I don't
bother with a loop which would have to (a) extract each element, and
build a type/header for it, and (b) have the overhead of calling
primitives 10000 times).

Of course, I don't use ML, so I don't know how applicable these
comments are to programs written in ML.  Your mileage may vary.  Void
where taxed or prohibitted.  Prices may be higher west of the
Mississippi.  Batteries not included.  NO WARRANTEE (This information
provided without warra...

Raul Rockwell