[Python-ideas] The case against static type checking, in detail (long)
tony at PageDNA.com
Thu Apr 26 21:39:39 CEST 2007
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
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
> 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
> 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
is shifted from human inspection and possibly incomplete tests, to
Its like having a computer check all of the cross brace connections.
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
to put your hand gets in the way of thinking about where to put your
Proposals for static type checking in Python have long included the
optional type checking where programs without declarations continue
to run. So
clearly the desire not to clutter or force work on a type-declaration
is already taken as a requirement.
More information about the Python-ideas