[
Lists Home |
Date Index |
Thread Index
]
On Wed, 5 Jan 2005, Uche Ogbuji wrote:
> On Wed, 2005-01-05 at 09:57 -0600, Bullard, Claude L (Len) wrote:
> > Umm... it may not catch all but it may catch most and
> > that may be good enough or as good as it gets.
>
> What do you mean by "it" in the above sentence? Do you mean "static
> type checking"? If so, what makes you think that?
Maybe just personal experience. I still vividly recall excitement of
learning to program in Standard ML about 10 years ago (after having had
some experience with Pascal, Lisp/Scheme, C++, Prolog): the type checker
would catch lots of coding mishaps that I previously had to debug during
testing. A simple program, after being Ok'ed by the typechecker, would
just run correctly the first time -- a big rarity in my prior experience.
Of course, more complex programs can still contain errors, but of more
serios nature, "logical", or "modeling". Type systems are too simple
mechanisms to catch those. One point static typing proponents make is:
Why one should write unit tests to check for simple errors, if those
can be checked automatically by a compiler? Moreover, the compiler can
_guarantee_ that a whole class of errors was cleared out from the
program. Unit tests are a potentially powerful, but a more expensive
technique, so after the static typechecker has cleared out simple bugs,
unit tests (and other testing techniques) can concentrate on verifying
more complex requirements.
If you did have experience programming in a modern strongly and statically
typed language like SML, OCaml, or Haskell, and still do not see their
benefits... I am sorry for the above lecturing. Perhaps it is useless to
spend your energy on discussions like this -- static typing enthusiasts
are as convinced in their point as you are in yours.
If the situation is opposite, you can be pleasantly surprized how close to
Python those languages are!
Cheers,
Vladimir
|
