Typing system vs. Java

[Donn Cave]

Quoth Chris Barker <chrishbarker at home.net>:
| Terry Reedy wrote:
|> "Donn Cave" <donn at u.washington.edu> wrote in message
|> news:9ka118$mj8$1 at nntp6.u.washington.edu...
|>> And the run time error is a TypeError: unsubscriptable object.
|>> He's baffled enough by this to post to comp.lang.python instead
|>> of figure it out himself.
|> 
|> What we need here are better error messages: a more explicit 'none
|> object is not subscriptable' might have steered him to the problem.
|
| That would help, as would any number of debugging techniques that any
| Python programmer with any experience would know. However, these would
| only work if, in fact the author checked his code with invalid data. It
| could be a long time before an error like that was found. Frankly, not
| thinking to handle the case of invalid data would be likely to bite you
| in any language, and I imagine that it is rare that type checking would
| find it very often.

Not sure what that last clause meant (rare that ... very often?) but
I guess this depends on the relationship between "thinking to handle
the case of invalid data" and type consistency.

If you decide to ignore his probable intention (did he think about
invalid inputs or not?), then the flaw in his program really was a
inconsistency between the function that could return None and caller
who failed to account for that.  Either in isolation is arguably fine
(maybe None is the right thing to return for an unmatched case), the
problem is that they don't match, an inconsistency that could have
been caught.

Of course a program can be written that will be perfectly type
consistent but still vulnerable to unexpected inputs.  But on
the other hand, you can use the enforced consistency of a type
checking language to help avoid accidents of that nature.
>From this point of view the language is not just the rules, but
the idioms that apply those rules as a programming tool.  If you
use type checking in this more active sense, I bet you can avoid
a significant number of unexpected input problems.

	Donn Cave, donn at u.washington.edu