Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!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: <17MAR91.21285518@uc780.umd.edu>
Date: 17 Mar 91 21:28:55 GMT
References: <602@optima.cs.arizona.edu> <1991Mar14.151707.11686@maths.nott.ac.uk>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 72
Nntp-Posting-Host: uc780.umd.edu

Dr. Walker writes:
>In article <602@optima.cs.arizona.edu> gudeman@cs.arizona.edu
>(David Gudeman) writes:
>>				   Mathematical notation is generally
>>closer to dynamically typed languages than to statically typed
>>languages.
> 
>	& it was invented and had evolved long before the whole modern
>problem of trying to describe problems and algorithms in a precise way
>for computer consumption.  Such examples as we have of attempts at
>precision in maths [eg, by Russell] are not very convincing.  We write
>sloppy maths because "we all know what we mean" -- I don't think that's
>a very good model for computer languages.

As one of my profs had to continually explain to me (when I made
similar complaints about mathematical notations), it's primarily a
matter of definitions.  

In any event, the number of statements you use to make a declaration
has very little to do with how 'mathematical' you are being.  I've
seen many, many statements of the form 'x element of set y, x takes on
value z.' ...   Quite similar to the sort of things required in a
statically typed language.

On the other hand, just because a mathematical statement doesn't fit
within the confines of some brand C statically typed language is no
reason to call it sloppy.  Mind you, I'm not trying to argue for
Russell's stuff...  I'd hate to try and implement code for it :)

>>With static typing you need a great deal of information at compile
>>time to be able to guarantee strong typing.  This has two
>>consequences: (1) you have to limit the forms of expressions to some
>>set for which you know a type-checking decision procedure, and (2) you
>>have to acquire type information somewhere.
> 
>	Ie, (1) you have to know what your expression is intended to do,
>and (2) you have to use variables in a disciplined way.  I don't find
>these "consequences" either irksome or undesirable.  When I write programs
>in dynamically typed languages, I try hard to follow the same precepts.

Indeed, but I find generalizing quite difficult in the statically
typed languages I've run across.  There is, of course, C's approach
(declare a prototype array, alloc some memory, declare it to be of
type 'prototype array', and ignore the phony array boundaries), but
that's just too much busy work for me.  Then there's the wonderful
idea of allocating a gob of memory and hoping it's enough.  Then
there's the technique of re-compiling the program for each instance of
the problem (a real speed demon if you need to run several hundred
thousand cases of each 'instance').

>	There is a place for dynamic typing (I enjoy writing shell
>scripts!), and a case for rapid prototyping, but there is also a
>case for traditional declarations;  there is no need for either
>"camp" to knock the other.

Quite true.

However, it's a bit ironic that things as inefficient as shell scripts
(with the attendant overhead of massive file operations and forks and
so on) go hand in hand with statically typed languages (with claims of
awesome efficiencies).  It's even more ironic when a program written
in a statically typed language will rely on heavy file manipulation
because they can not deal with memory with enough abstraction.

I'm also rather amused (if only it weren't so painful) by the amount
of memory required by statically linked programs.  And by things like
fixed sized buffers, with system calls that haven't a clue as to that
size.  Ah... the wonderous maintainability of statically typed code...

;)  *sigh* :(

Raul Rockwell