[Python-ideas] The case against static type checking, in detail (long)

[Tony Lownds]

On Apr 25, 2007, at 10:59 PM, Talin wrote:
> However, we find in practice that much of the programmer's effort is
> spent in maintaining this cross-checking structure.

How does this effort compare to writing all of the equivalent type  
tests?
Static type checking subsumes the need to write tests to ensure that for
every operation, the inputs are valid types, and the result type will  
be a
valid type.

> To use a building
> analogy, a statically-typed program is like a truss structure, where
> there's a complex web of cross-braces, and a force applied at any  
> given
> point is spread out over the whole structure. Each time such a program
> is modified, the programmer must partially dismantle and then
> re-assemble the existing structure.

However the work to ensure the re-assembled structure is completely  
valid
is shifted from human inspection and possibly incomplete tests, to  
static analysis.
Its like having a computer check all of the cross brace connections.   
When the
modifications are small dismantle/reassmbly costs can be dominated by
the checking costs.

> Yes, static type checking
> does detect some errors; But it also causes errors by making the code
> larger and more wordy, because that the programmer cannot hold large
> portions of the program in their mind all at once, which can lead to
> errors in overall design. It means the programmer spends more time
> thinking about the behavior of individual variables and less about the
> algorithm as a whole.

Thats like saying stairs should not have rails because thinking about  
where
to put your hand gets in the way of thinking about where to put your  
feet!

Proposals for static type checking in Python have long included the  
concept of
optional type checking where programs without declarations continue  
to run. So
clearly the desire not to clutter or force work on a type-declaration  
averse programmer
is already taken as a requirement.

-Tony