Xref: utzoo comp.object:3247 comp.lang.misc:7527
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.object,comp.lang.misc
Subject: Re: Run-time Type Errors in Smalltalk
Message-ID: <530@eiffel.UUCP>
Date: 19 Apr 91 00:48:36 GMT
References: <3865@ssc-bee.ssc-vax.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 66

From article <3865@ssc-bee.ssc-vax.UUCP>
by dmg@ssc-vax.uucp (David M Geary):

> 1)  Since dynamic typing allows more expressiveness and a greater degree
>     of reusability than a statically typed language, code in a statically 
>     typed language may be 10% (or more) larger than the "same" code in a 
>     dynamically typed language.  So, while some errors have been ironed out
>     before testing, testing may have more to test.

The premise of this sentence (a statically typed language is less
expressive) is, I believe, incorrect. With the appropriate
typing facilities (in particular genericity, constrained and
unconstrained) you lose absolutely nothing in expressiveness.
This has been discussed at length in this newsgroup before,
and in spite of many efforts and even ``challenges''
I don't think anyone has shown a convincing counter-example -
something that could be expressed conveniently in a dynamically
typed language but not in a statically typed language.
(Again, I am assuming a decent type system; if you don't have
genericity, or if arbitrary C-like casts are allowed,
this is all meaningless anyway.)

Mr. Geary is quite correct, however, that a statically typed language
will be slightly more verbose because of the need for declaring
entities (attributes, local variables, function results).
But this should have at most a negligible effect on testing.
Typically, one tests the executable parts of a software system
(the instructions), not the declarations. In fact, the presence
of declarations may be a significant help in eliminating useless
tests and making each individual test more productive.
(The same applies to assertions, but that's another story.)

It is true, of course, that as soon as you introduce more text
(such as declarations) you introduce more possibilities of error.
This is because static typing follows the time-honored method
of introducing redundancy to make it easier to catch errors.
The reason this is a good method is that more
redundancy means more likelihood that a conceptual error will
become an *inconsistency*, and inconsistencies are always
much easier to detect than more general types of errors.
The catch is that you may then detect inconsistencies which
are *not* original errors: for example, they may result from errors
in the elements that have been added for redundancy. (This occurs
for example when a variable is used properly, but its declaration
is ``wrong'' with respect to the programmer's intent.)

This means that when you add redundancy for security there is a risk
of false alarm (detecting an apparent error when the original was in
fact correct). If, as is the case in the practice of reasonable
statically typed languages, such false alarms are rare, the price
is acceptable, being justified by all the *real* alarms that
redundancy will enable you to catch.

As an analogy (offered for what it's worth), in some countries
elementary school students are (were?) taught to check
an arithmetic operation by ``crossing out nines'' (``preuve par 9''),
which is a quick modulo-9 check. Once in a while you will find
an inconsistency which results from an error in the crossing-out,
not in the original operation. However this occasional nuisance
- which merely forces you to redo the operation and the check -
is nothing to complain about when compared to all the
*real* errors that this type of checking catches.
-- 
-- Bertrand Meyer
Interactive Software Engineering Inc., Santa Barbara
bertrand@eiffel.uucp