Flying With Python (Strong versus Weak Typing)

[Alex Martelli]

Donn Cave wrote:

> Quoth Alex Martelli <aleax at aleax.it>:
> | 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.
   ...
> | 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.
> 
> But earlier you said static typing ``may slightly enhance programmer
> productivity'', which meant to me that N can be negative, in which
> case Q is certainly larger than X.  That was the point that I thought
> rather generous of you to concede.

Ah, the "depending on other issue" parenthesis was clearly too
elliptical (referring in just a few words to the tens of thousands
of words I've written on the subject over the years).  Catching an
error a few minutes earlier, _all other things being equal_, can
slightly increase your productivity -- but other things are more
often very different, because of the sheer design and coding
overhead you pay for that tiny advantage.  Think, for example, of
the huge complication and fragility of the Visitor design pattern
in statically typed languages, and of how many "typos caught two
minutes earlier" it would take to pay for THAT productivity impact.

If you're doing no testing at all, or extremely limited testing,
then any crutch can be of some help in enhancing your overall
lifecycle productivity -- it will inevitably remain in the "total
disaster" zone, but within that unacceptable region there is still
space for different magnitudes of horror and disasters.  This is
the only scenario where I can think of "N being negative", i.e., of
_overall_ productivity increase -- otherwise, the "local" positive
effect of getting some small subset of your errors diagnosed 
marginally earlier will be swamped by Visitor and the like.  But
the "no or too-limited testing" scenario is of no relevance
whatsoever to the development of life-critical software.

Thus, your assessment of my assertion as "generous" was predicated
on my expression being too elliptic.


> If you go that way, for free or at negative cost you catch Q errors
> that you can't guarantee will be caught any other way in bounded

I can guarantee with 100% certainty that any software whose test 
suite doesn't catch ALL the errors that static-typing would catch
is totally unacceptable for ANY life-critical application.  Think
of a statement: a=b+c.  If the test suite does not exercise this,
then it's possible that b and c are of types that don't support
being added to each other, and that a static type-check would
catch this.  *BUT* -- if the test suite does not exercise this, it
is quite possible that what was meant was a=b-c -- when the types
of b and c support both addition and subtraction (the most common
case, excepting only a few overloads such as Pythons' "sequence
concatenation" use for +, or C's pointers), static type checks
are powerless, and tests are necessary.

> time.  If that doesn't have any bearing on life critical applications,
> I am going to stick to my bicycle.

A life-critical application MUST at a very minimum have a large
test suite that catches all errors that static typing would have
caught, and then some.  If you know that the application skimps
on tests, to the point of not exercising some parts enough to catch
such errors, and if you have any way to avoid relying on the
application, then the choice to avoid relying on it is sound!


Alex