"Strong typing vs. strong testing"

Pascal J. Bourguignon pjb at informatimago.com
Mon Sep 27 21:29:44 CEST 2010


namekuseijin <namekuseijin at gmail.com> writes:

>> 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?
>
> this works at compilation time without warnings:
> int m=numbermax( 2, 6 );
>
> this too:
> int a, b, m;
> scanf( "%d", &a );
> scanf( "%d", &b );
> m=numbermax( a, b );
>
> no compiler issues, but will not work just as much as in python if
> user provides "foo" and "bar" for a and b... fail.
>
> What you do if you're feeling insecure and paranoid?  Just what
> dynamically typed languages do:  add runtime checks.  Unit tests are
> great to assert those.
>
> Fact is:  almost all user data from the external words comes into
> programs as strings.  No typesystem or compiler handles this fact all
> that graceful...


I would even go further.

Types are only part of the story.  You may distinguish between integers
and floating points, fine.  But what about distinguishing between
floating points representing lengths and floating points representing
volumes?  Worse, what about distinguishing and converting floating
points representing lengths expressed in feets and floating points
representing lengths expressed in meters.

If you start with the mindset of static type checking, you will consider
that your types are checked and if the types at the interface of two
modules matches you'll think that everything's ok.  And six months later
you Mars mission will crash.

On the other hand, with the dynamic typing mindset, you might even wrap
your values (of whatever numerical type) in a symbolic expression
mentionning the unit and perhaps other meta data, so that when the other
module receives it, it may notice (dynamically) that two values are not
of the same unit, but if compatible, it could (dynamically) convert into
the expected unit.  Mission saved!


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/



More information about the Python-list mailing list