I come not to bury C++, but to praise it...
John J. Lee
jjl at pobox.com
Thu Jan 15 03:24:08 CET 2004
"Derek" <none at none.com> writes:
> Yes, I prefer compile-time checks to run-time checks. I don't know
> which method is "better" by any objective measure, but I prefer to
> know if there is a problem as early as possible. It's not hard to
It would certainly be better if Python had some kind of optional
static type checking (though that seems unlikely to happen). Many
people (eg. Alex Martelli in this group) have argued that requiring
*everything* to be statically checked is harmful because of the cost
it imposes in terms of inflexibility and lines of code.
> make a change in Python that will go unnoticed until much later, and
> in the real world test suites often don't have enough coverage to
> catch every runtime error up front.
The argument runs like this: If you don't have near-100% test
coverage, you are missing many bugs that static typechecking will not
catch. So don't do that (the fact that it's perfectly feasible to
have near-100% coverage, when given support from bosses where
relevant, has been repeatedly demonstrated recently). OTOH, if you do
have 100% coverage, the set of bugs that *are* caught by the static
typechecks, but *not* by the tests is usually very small, in practice.
So, you can catch bugs by introducing static checks, but you introduce
*even more* bugs (so the argument runs) if you pay the cost (see
above) of static checking for *everything*, as you must in C++. So,
though Python beats C++ here, the even-happier medium is achieved with
systems like the static type-inference of ML and Haskell. Whether
this argument holds in general is hard to answer, but in the
particular case of C++ and Python, I find it extremely persuasive.
More information about the Python-list