Who's minister of propaganda this week?
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Sun Mar 18 15:13:47 CET 2001
Thu, 15 Mar 2001 05:43:38 -0800, Paul Prescod <paulp at ActiveState.com> pisze:
> 3. Statically typed languages are absolutely not immune to type errors
> for a variety of reasons:
> * Null pointer exceptions are type errors. You've passed the null
> object when the code expected some other object.
Not all languages have null pointers at all. (My favorites happen
not to have them.)
> * Almost every statically typed language also has a set of features for
> working around the type system (dynamic casts).
In many languages (Haskell, SML, OCaml, Clean, Mercury, Eiffel) they
are almost never used. Again, not all languages are like C++ and Java
where casting is essential.
> * Even when the compiler thinks the "type" of your object is correct,
> there are a variety of type-related errors you can make such as passing
> a negative number where only positive ones are allowed,
Indeed. Nobody claims that static type system catch all type-related
errors. But they catch most of them, and it's better to catch some
than to catch none. The inability to catch all type-related errors
at compile time is hardly a disadvantage of static type systems wrt.
dynamic type systems, if dynamic type systems don't catch any of them
at compile time.
> 4. Yes, if you unit test every unit in your program, and do good
> coverage testing you WILL catch ever occurrence of some code calling
> foo. That's what good testing is about. And you need it, not to catch
> the basic type errors but to catch the subtle semantic errors. Catching
> the basic type errors comes for free.
This assumes that testing procedures are perfect and cover every
possible kind of data. Nobody's perfect. Tests still catch only
a proper subset of what static typing + tests catch together.
__("< Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA
More information about the Python-list