Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ucbcad.UUCP
Path: utzoo!linus!security!genrad!grkermit!mit-vax!eagle!harpo!floyd!vax135!cornell!uw-beaver!tektronix!ucbcad!ucbesvax.turner
From: ucbesvax.turner@ucbcad.UUCP
Newsgroups: net.lang
Subject: Re: Whats wrong with strong typing - (nf)
Message-ID: <1128@ucbcad.UUCP>
Date: Sat, 24-Dec-83 01:23:03 EST
Article-I.D.: ucbcad.1128
Posted: Sat Dec 24 01:23:03 1983
Date-Received: Thu, 22-Dec-83 00:23:06 EST
Sender: notes@ucbcad.UUCP
Organization: UC Berkeley CAD Group
Lines: 51

#R:yale-com:-258200:ucbesvax:4500006:000:2535
ucbesvax!turner    Dec 15 15:51:00 1983

/***** ucbesvax:net.lang / yale-com!leichter /  6:17 am  Dec 14, 1983*/
								...that the
    "problem" being solved by most strong-typing systems - compile-time checking
    for inconsistencies - is just NOT a significant problem in real life.
			   ...Problems I do find are more subtle and often have
    to do with order and meaning of arguments to functions that take many argu-
    ments - but usually there are multiple arguments of the same type so a
    typing system wouldn't catch them anyway.

How ironic--just 1/2-hour ago I fixed a bug of this kind.  The function took
four arguments, only two of which were integers.  In pascal (I'm writing in
C), they would have been "var integer".  The formal parameter names were
"ncols" and "nrows"--in that order.  The user of this routine confused the
order (quite naturally--most of us prefer to say "rows and columns" to
"columns and rows"), which blew up his code.  If C had better strong typing,
I would have solved this by having types "rowval" and "colval".  As it is,
we limp along, being quite poor programmers by Jerry's definition.  We do
terrible things like forget argument-order even for functions with small
numbers of arguments.

I am currently in the position of helping to support some channel-routing
code.  It has about 40 integer-type variables global to the whole routine.
Most of these are indices to very specific arrays.  The author didn't
type them as being specific subranges.  We wish that he had.  The algorithm
is published, and easily understood, but the code is a mess.  Strong typing
would have helped both in terms of maintenance and in making the code more
self-documenting.

(No, I don't claim that strong-typing makes programmers better.  But I do
believe that better programmers employ it, because they know better than
to believe for a minute in their own perfection.)

Re: declaration of functions as recursive

This is irrelevant to the discussion of the relative merits of strong typing.
When is such a distinction important for the kinds of uses to which strong
typing is put?  "recursive foo()" is a COMPILER-directive, implying that
recursiveness is a consideration in producing code that is faster or correctly
implemented.  It would never be a consideration in a statement like

	<fn ref 1> := <fn ref 2>

where one would certainly want to know that fn2 returned something of a type
castable to the return-type of fn1.  Jerry is making an argument by analogy,
the analogy does not exist.
---
Michael Turner (ucbvax!ucbesvax.turner)