[Python-ideas] The case against static type checking, in detail (long) (original) (raw)
Tony Lownds tony at PageDNA.com
Thu Apr 26 21:39:39 CEST 2007
- Previous message: [Python-ideas] The case against static type checking, in detail (long)
- Next message: [Python-ideas] The case against static type checking, in detail (long)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-ideas] The case against static type checking, in detail (long)
- Next message: [Python-ideas] The case against static type checking, in detail (long)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]