"Strong typing vs. strong testing"

[Albert van der Horst]

In article <87fwwvrnmf.fsf at kuiper.lan.informatimago.com>,
Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>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.

When I was at Shell (late eighties) there were people claiming
to have done exactly that, statically, in ADA.
I would say the dimensional checking is underrated. It must be
complemented with a hard and fast rule about only using standard
(SI) units internally.

Oil output internal : m^3/sec
Oil output printed:  kbarrels/day

>
>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.

A mission failure is a failure of management. The Ariadne crash was.
Management must take care that engineering mistakes don't lead to
mission failure. In the Ariadne case it was not so much engineering
mistakes, but management actually standing in the way of good
engineering practice.

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

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst