"Strong typing vs. strong testing"

[bearophile]

A long thread on comp.lang.python (with some cross-posting). Most of it is made by boring or useless stuff, or by wrong ideas, but it contains few interesting bits, "Strong typing vs. strong testing":
http://groups.google.com/group/comp.lang.python/browse_thread/thread/f124e5961b1a3ac5

It talks about bugs and how to avoid them, etc. In some of those posts as example they use a max() function that returns the maximum among two integers. The whole discussion has confused me a little, I can't develop a definite opinion on the whole thread.

In the discussion they have forgotten to list two other strategies to write correct programs (beside unit testing and good static typing):

- What I call "Contract-Driven Development", (where usually contracts are not enforced statically);
- Static verification of the code, as done by Spark and similar sub-languages for C too (but this kind of programming today requires lot of brain and time/money, so I think it's currently justifiable only for uncommon critical systems).


One quotation from the thread:

> Our experience is that a garbage collector and native bignums are much more
> important [than static strong typing] to minimize the number of problems we run
> into during development and the number of bugs that are in the finished products. 

In Python all integer numbers are multi-precision, and in theory there's a risk that some numbers grow so much to produce memory overflow, but this has never happened to me, and in practice I think Python code contains much less integer-related bugs compared to C/Java/D code.

Pascal/Delphi/C# use a third approach, they perform runtime tests against integer overflows (this also avoids the memory overflows of the multi-precision numbers). (I have taken a look at the usage of the 'checked' keyword in C#: checked 17800 results:
http://www.google.com/codesearch?q=\Wchecked\s%3F[\{\%28]+lang:c%23 ) While in Delphi/FreePascal they are active on default (almost), so you use those tests often (and they avoid you several bugs, especially when you use short integers or bytes).

In D I use both the strict type system, many unittests, run-time enforced Contracts, and the GC to avoid some memory-related bugs. And I'd like integral overflows too.


In that thread someone has suggested to design a language that groups all the safety feateres, with static type system, and multi-precision numbers too on default as in Python. I don't know if such language exists, but people seem to like an average risk, so maybe people will not appreciate such language much because of risk homeostasis:
http://en.wikipedia.org/wiki/Risk_homeostasis
So the programmers of such language may then seek for risks in other directions :-)


A comment about Lisp dynamic typing compared to the C++ static typing:

> how much time does it take me to ship a
> debugged system?  Working in Lisp, sometimes I don't get immediate
> feedback from the compiler that I've done something stupid, but this is
> generally counterbalanced by the ease of interactive testing, that
> frequently allows me to run a new piece of code several times in the
> time it would have taken me to do a compile-and-link in, say, C++. 

This is true, Python lets you have a little more type-related bugs, but it also gives you a higher programming speed, to perform experiments too, so you are able to fix those bugs in less time.


The static verification of the code is an interesting idea, and it's useful for some niche purposes, even if you need lot of brain to use it for real. A problem of such demonstrations (mostly done by automatic tools) is that I think they don't take into account that the hardware is not perfect, see for example: "Google: Computer memory flakier than expected":
http://news.cnet.com/8301-30685_3-10370026-264.html
It's conceivable the creation of demonstrations that keep into account even such bugs (with software/algorithm-level correction schemes, etc.), but I've never seen them yet and they probably make the demonstrations even more complex.

Another thing I'd like to say is that I've seen lot of programmers don't use Lint tools. This means that it's useful to add some basic lint-tool-like capability to the compiler of modern languages as D (and indeed, the C# compiler performs many tests that were once done by the C lint only).

Bye,
bearophile