"Strong typing vs. strong testing"
rui.maciel at gmail.com
Fri Oct 1 15:12:43 CEST 2010
>> in C I can have a function maximum(int a, int b) that will always
>> work. Never blow up, and never give an invalid answer. If someone
>> tries to call it incorrectly it is a compile error.
>> In a dynamic typed language maximum(a, b) can be called with incorrect
>> datatypes. Even if I make it so it can handle many types as you did
>> above, it could still be inadvertantly called with a file handle for a
>> parameter or some other type not provided for. So does Eckel and
>> others, when they are writing their dynamically typed code advocate
>> just letting the function blow up or give a bogus answer, or do they
>> check for valid types passed? If they are checking for valid types it
>> would seem that any benefits gained by not specifying type are lost by
>> checking for type. And if they don't check for type it would seem that
>> their code's error handling is poor.
> that is a lie.
> Compilation only makes sure that values provided at compilation-time
> are of the right datatype.
> What happens though is that in the real world, pretty much all
> computation depends on user provided values at runtime. See where are
> we heading?
You are confusing two completely different and independent concepts, which is a language's typing
sytem and input validation. TheFlyingDutchman pointed out the typical problems associated with
weakly typed languages while you tried to contradict him by complaining about input sanity issues.
The thing is, input sanity issues are perfectly independent of a language's typing system.
Therefore, arguing about the need to perform sanity checks on programs written on language X or Y
does nothing to tackle the issues related to passing a variable/object of the "wrong" type as a
parameter to some function.
More information about the Python-list