Flying With Python (Strong versus Weak Typing)

[Alex Martelli]

Donn Cave wrote:

> Quoth Alex Martelli <aleax at aleax.it>:
> ...
> | Static typing makes it easier for the compiler to generate fast
> | code, and (depending also on other issues) may slightly enhance
> | programmer productivity by catching a small percentage of errors
> | a bit earlier than testing would catch them -- that's all.  It has
> | no real bearing on safety issues for life-critical software.
> 
> I think this is the most generous posture I've seen you take on
> this issue, so I should probably leave well enough alone, but ...

Not sure what you mean by "generous" -- it's the stance I've
always had.  _In theory_ a compiler can (if you provide it with
the complete sources, etc, etc) infer types and generate all checks
and optimal code and so on, _in practice_ such a compiler will be
too complicated (and sometimes may need to solve problems that
are equivalent to the halting problem...), so that "hints"
optionally or mandatorily provided by the programmer can help.

I've often daydreamed about having a language where I can offer
such hints and compile my programs in at least two ways:

-- a debugging mode, where hints let the compiler insert checks
   for me and raise warnings or errors when my hints don't match
   reality,
-- an optimizing mode, where the compiler trusts the hints (at
   least to some extent) and uses them to make fast code.

But static typing doesn't come close to making the daydream any
closer to true -- often such hints would be things of the form, e.g.:
    x > y
rather than ones of the form, e.g.:
    isinstance(x, y)
and why should I use a language that arbitrarily lets me (or even
forces me to) offer hints of the latter and not of the former kind?


> This seems to be a matter of one's faith in some set of techniques
> that an engineering team can use to write correct software.  The
> Python world seems to place a great deal of faith in testing.
> Statically typed languages can test, too, so the bottom line must
> be whether testing is such a perfect solution that anything else -
> like computer analysis of the program for structural correctness -
> is irrelevant.  Interesting question.  I don't understand testing,

"irrelevant" is the wrong criterion to apply to this engineering
question, in my opinion.  Any real-world system is developed under
constraints of budget and deadlines.  If static typing decreases
overall programmer productivity by N% (so that N% fewer tests will
get written given the budget/timing constraints) but by hypothesis
catches Q% more errors in absence of tests, then the right check
is not whether Q > 0 -- it's whether Q > X where X% are the errors
caught by having N% more tests.

If you had unlimited resources and could take unbounded time before
you delivered a system, then you might be able deliver a system with 
0 errors, almost independently of choice of methodologies and tools.  
But such a hypothetical issue is of no real-world interest.

> to me it seems highly vulnerable to human weaknesses like making
> invalid assumptions, and it seems vulnerable to inaccuracies in
> the simulation of the program's intended environment.

Definitely!  The tests can be see as embodying, in objectively
verifiable form, the SPECIFICATIONS of the system.  As such, they
are subject to exactly the same frailties as specifications are --
PLUS issues of computability (any universal quantifier of the
form "for any X ..." is untestable unless X is further specified
to belong to, not just any FINITE set, but indeed a finite set
with "small" cardinality!).

This goes a good way towards explaining why UNIT tests are so
popular -- a UNIT can be specified more thoroughly and precisely,
because it has a more delimited and definite job than the whole,
larger system of which the unit is a part -- and thus more
testable.

But similar issues apply to "proofs of correctness" -- which
can be nothing but proofs of adherence to specs... if the specs
are bogus, the proofs are nowhere as practically valuable.


Alex