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