• bearophile (22/31) Oct 12 2010 A long thread on comp.lang.python (with some cross-posting). Most of it ...

bearophile <bearophileHUGS lycos.com> writes:

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.


integer overflows (this also avoids the memory overflows of the multi-precision

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

compiler performs many tests that were once done by the C lint only).

Bye,
bearophile