I come not to bury C++, but to praise it...

[John J. Lee]

"Andrew Koenig" <ark at acm.org> writes:

> > 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.
> 
> There is a subtle fallacy in this argument, at least in the context of C++
> and Python, namely that there is a significant category of errors that
> static type checking (as C++ and some other languages do it) can detect but
> can escape even 100% test coverage.

It may be subtle, but it's also the starting point for most of these
debates.


> Before you get out your flame-thrower, please hear me out -- I am not saying

OK... :-)


> that this reasoning applies to all errors, or even a majority of them, but
> only to a significant category.  That category consists of programs where
> the types of key objects are not known when the program is written, but are
> known when the program is compiled.

Agreed.

[...snip example...]
> In practice, C++ programmers often solve such problems by using templates,
> which defer type checking until the last possible moment during the
> compilation process.  In effect, the compiler looks at each call to our
> hypothetical sort function, and verifies that the type assumptions that the
> sort function makes are valid in the context of that particular call.  The
> result is that the compiler can detect type errors that would show up in a
> dynamically typed environment only if the function were tested with the
> specific types that revealed the error.

Yes.


> The price one pays for this extra checking, of course, is that one cannot
> call such a sort function with an argument with a type that is known only at
> run time.  But in practice, there are many cases where being able to defer
> type checking until the end of compilation is just as useful as being able
> to defer it until run time.  I believe that many people who dislike static
> type checking are unaware of this distinction.

I do like static type checking.  I *don't* like the price that C++
makes me pay for it in terms of lines of code and inflexibility.  When
comparing Python and C++, the longer, more inflexible programs
required to solve problems in C++ introduce more bugs than its static
typechecking system removes.  It's a shame some tiny fraction of the
trillion dollars recently allocated to George Bush's electoral
campaign <0.2 wink> can't be diverted to experiments to test this
hypothesis (but I guess those dollars are mostly fictional anyway ;-).

So, I think the various interface proposals that have been made for
Python are interesting.  Also, it seems attractive to have static type
inference wedged into Python somehow (not holding my breath: I don't
even know if that idea really makes any sense in the context of
Python).  But I see Python in its current state as a safer language
than C++.

Alex Martelli goes much further than I do:

http://www.google.com/groups?selm=ft6tb.21351%249_.767461%40news1.tin.it&rnum=1

[...]
> I see static typing
> as a theoretically-interesting field of no real applicability to my
> work.  If I felt otherwise about it, I would most likely be coding
> in Haskell or some kind of ML, of course -- nobody's come and FORCED
> me to choose a dynamically-typed language, you know?

And perhaps he's right: my attraction to static type inference in a
Python-like language is both theoretical and almost maximally vague
(and my grasp of the issues is weaker than Alex's), and I don't have
any decent ML or Haskell experience with to compare with my Python
experience...

See also the couple of posts near this article in the exchange between
Alex and David Abrahams (same one I posted in a followup to Cameron
earlier):

http://www.google.com/groups?selm=pNfIa.206219%24g92.4232233%40news2.tin.it&rnum=2


John