RE: dynamic vs. static typing

["Anton van Straaten" <address@hidden>]

Steve Dekorte:
> On Nov 24, 2003, at 11:48 PM, Anton van Straaten wrote:
> > I'm reminded of the argument about wearing helmets on a bicycle or
> > motorcycle: head injuries actually aren't that high a proportion of the
> > injuries that occur during accidents, so why wear a helmet?
>
> Because the type of accident is worse (broken skulls are less desirable
> than broken arms). In the case of programming, I don't see how it's any
> worse to raise a "does not respond" error than to produce the wrong
> result.

It's worse because it happens later, including at runtime - keeping in mind
that unit tests can't guarantee to find a certain class of errors, as type
checking can.  In addition, even if the unit tests do catch the error, the
cause may not be as clear, i.e. you find the consequences of the error, not
the error itself, and have to trace back to figure out the cause.

A 'does not respond' error is a best case.  A worse case is sending a
message to the wrong object that appears to be understood - exactly the kind
of error that can slip through unit tests to manifest at runtime.

Of course, to help with this, you can do *some* typechecking assertions in
your unit tests, but in that case, you'd be doing a limited version of what
I've been advocating: type checking prior to runtime, only in a set of
separate custom-written programs, i.e. "the hard way".

> > Anyone who's made serious use of a language with a good static
> > typesystem has experienced this.  Think of it as a way to get
> > an entire class of high-performance unit tests without having
> > to actually write them.
>
> What class is that? If we are already testing for correctness of
> results, shouldn't that expose any "does not respond" errors of
> interest?

See above: (a) unit tests can't guarantee the same sort of coverage, and (b)
the cost of finding the errors increases.

I'm obviously not advocating not using unit tests - but there's useful
checking that can be performed even before unit testing, and that checking
can make the developer's work easier.  This goes double when multiple
developers are involved: i.e. contracts between modules are checked
automatically and early.

One way to think of it is like security policy: multiple layers are better.
Static type checks - even partial ones - can act as a filter which can
prevent errors that may even be able to slip through unit testing, to
runtime.  Substituting one layer for another layer, when the two layers have
different purposes, doesn't produce an equivalent result.

Anton