program surgery vs. type safety

Jeremy Fincher tweedgeezer at hotmail.com
Fri Nov 14 07:17:08 EST 2003


Alex Martelli <aleax at aleax.it> wrote in message news:<QAOsb.21403$hV.779611 at news2.tin.it>...
> Sure,
> "tests can only show the _presence_ of errors, not their
> _absence_".  But so can static, compiler-enforced typing -- it
> can show the presence of some errors, but never the absence of
> others ("oops I meant a+b, not a-b"! and the like...).

But it *does* show the absence of type errors, and almost any
invariant can be coded into the Hindley-Milner typesystem.  Writing to
a file opened for reading, multiplying matrices with improper
dimensions, etc. are both (among others) valid for encoding in the
typesystem.  Too many dynamic typing advocates look at a typesystem
and see only a jail (or a padded room ;)) to restrict them.  A good
static typesystem isn't a jail, but the raw material for building
compiler-enforced invariants into your code.  Think DBC that the
compiler won't compile unless it can *prove* the contract is never
violated.

The main point, however, you made yourself: tests can only show the
*presence* of errors, whereas static typing can prove their absence.

>  In my
> experience, the errors that static type-checking reliably catches
> are a subset of those caught by systematic tests, particularly
> with test-driven design.

But does the compiler write the tests for you?  At the very least, one
could argue that static typing saves the programmer from having to
write a significant number of tests.

>  But systematic use of tests also
> catches quite a few other kinds of errors, so, it gives me MORE
> confidence than static type-checking would; and the "added
> value" of static type-checking _given_ that I'll have good
> batteries of tests anyway is too small for me to yearn to go
> back to statically checked languages.

You make it seem like static typing and tests are mutually exclusive. 
Obviously, they're not, though admittedly when I programmed in O'Caml
I felt far less *need* for tests because I saw far fewer bugs.

Good thing, too -- the testing libraries available for O'Caml (like
most everything else for that language) are pretty nasty :)

Jeremy




More information about the Python-list mailing list