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