Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: "Strong typing vs. strong testing"

Reply
Thread Tools

Re: "Strong typing vs. strong testing"

 
 
namekuseijin
Guest
Posts: n/a
 
      09-27-2010
On 27 set, 05:46, TheFlyingDutchman <(E-Mail Removed)> wrote:
> On Sep 27, 12:58*am, (E-Mail Removed) (Pascal J. Bourguignon)
> wrote:
> > RG <(E-Mail Removed)> writes:
> > > In article
> > > <(E-Mail Removed)>,
> > > *TheFlyingDutchman <(E-Mail Removed)> wrote:

>
> > >> On Sep 22, 10:26*pm, "Scott L. Burson" <(E-Mail Removed)> wrote:
> > >> > This might have been mentioned here before, but I just came across it: a
> > >> > 2003 essay by Bruce Eckel on how reliable systems can get built in
> > >> > dynamically-typed languages. *It echoes things we've all said here, but
> > >> > I think it's interesting because it describes a conversion experience:
> > >> > Eckel started out in the strong-typing camp and was won over.

>
> > >> > * *https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk

>
> > >> > -- Scott

>
> > >> If you are writing a function to determine the maximum of two numbers
> > >> passed as arguents in a dynamic typed language, what is the normal
> > >> procedure used by Eckel and others to handle someone passing in
> > >> invalid values - such as a file handle for one varible and an array
> > >> for the other?

>
> > > The normal procedure is to hit such a person over the head with a stick
> > > and shout "FOO".

>
> > Moreover, the functions returning the maximum may be able to work on
> > non-numbers, as long as they're comparable. *What's more, there are
> > numbers that are NOT comparable by the operator you're thinking about!.

>
> > So to implement your specifications, that function would have to be
> > implemented for example as:

>
> > (defmethod lessp ((x real) (y real)) (< x y))
> > (defmethod lessp ((x complex) (y complex))
> > * (or (< (real-part x) (real-part y))
> > * * * (and (= (real-part x) (real-part y))
> > * * * * * *(< (imag-part x) (imag-part y)))))

>
> > (defun maximum (a b)
> > * (if (lessp a b) b a))

>
> > And then the client of that function could very well add methods:

>
> > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > (defmethod lessp ((x string) (y string)) (string< x y))

>
> > and call:

>
> > (maximum 'hello "WORLD") --> "WORLD"

>
> > and who are you to forbid it!?

>
> > --
> > __Pascal Bourguignon__ * * * * * * * * * *http://www.informatimago.com/-Hide quoted text -

>
> > - Show quoted text -

>
> 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...
 
Reply With Quote
 
 
 
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-27-2010
namekuseijin <(E-Mail Removed)> 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/
 
Reply With Quote
 
 
 
 
Scott L. Burson
Guest
Posts: n/a
 
      09-27-2010
Pascal J. Bourguignon wrote:
>
> 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!


In fairness, you could do this statically too, and without the consing
required by the dynamic approach.

-- Scott

 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-27-2010
"Scott L. Burson" <(E-Mail Removed)> writes:

> Pascal J. Bourguignon wrote:
>>
>> 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!

>
> In fairness, you could do this statically too, and without the consing
> required by the dynamic approach.


I don't deny it. My point is that it's a question of mindset.

--
__Pascal Bourguignon__ http://www.informatimago.com/
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      09-28-2010
On Sep 27, 7:46*pm, namekuseijin <(E-Mail Removed)> wrote:
> On 27 set, 05:46, TheFlyingDutchman <(E-Mail Removed)> wrote:
>
> 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...- Hide quoted text -
>

You're right. C should have a much better library than it does for
parsing user-supplied string input.

The scanf() family of functions is fine for everyday use, but not
robust enough for potentially hostile inputs. atoi() had to be
replaced by strtol(), but there's a need for a higher-leve function
built on strtol().

I wrote a generic commandline parser once, however it's almost
impossible to achieve something that is both useable and 100%
bulletproof.


 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      09-28-2010
On Sep 27, 9:29*pm, (E-Mail Removed) (Pascal J. Bourguignon)
wrote:
>
> 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!
>

I'd like to design a language like this. If you add a quantity in
inches to a quantity in centimetres you get a quantity in (say)
metres. If you multiply them together you get an area, if you divide
them you get a dimeionless scalar. If you divide a quantity in metres
by a quantity in seconds you get a velocity, if you try to subtract
them you get an error.

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      09-28-2010


"Malcolm McLean" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Sep 27, 9:29 pm, (E-Mail Removed) (Pascal J. Bourguignon)
> wrote:
>>
>> 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!
>>

> I'd like to design a language like this. If you add a quantity in
> inches to a quantity in centimetres you get a quantity in (say)
> metres. If you multiply them together you get an area, if you divide
> them you get a dimeionless scalar. If you divide a quantity in metres
> by a quantity in seconds you get a velocity, if you try to subtract
> them you get an error.


As you suggested in 'Varaibles with units' comp.programming Feb 16 2008?
[Yes with that spelling...]

I have a feeling that would quickly make programming impossible (if you
consider how many combinations of dimensions/units, and operators there
might be).

One approach I've used is to specify a dimension (ie. unit) only for
constant values, which are then immediately converted (at compile time) to a
standard unit:

a:=sin(60°) # becomes sin(1.047... radians)
d:=6 ins # becomes 152.4 mm

Here the standard units are radians, and mm. Every other calculation uses
implied units.

--
Bartc

 
Reply With Quote
 
Tim Bradshaw
Guest
Posts: n/a
 
      09-28-2010
On 2010-09-28 10:55:19 +0100, Malcolm McLean said:

> I'd like to design a language like this. If you add a quantity in
> inches to a quantity in centimetres you get a quantity in (say)
> metres. If you multiply them together you get an area, if you divide
> them you get a dimeionless scalar. If you divide a quantity in metres
> by a quantity in seconds you get a velocity, if you try to subtract
> them you get an error.


There are several existing systems which do this. The HP48 (and
descendants I expect) support "units" which are essentially dimensions.
I don't remember if it signals errors for incoherent dimensions.
Mathematica also has some units support, and it definitely does not
indicate an error: "1 Inch + 1 Second" is fine. There are probably
lots of other systems which do similar things.

 
Reply With Quote
 
Albert van der Horst
Guest
Posts: n/a
 
      09-28-2010
In article <(E-Mail Removed)>,
Pascal J. Bourguignon <(E-Mail Removed)> wrote:
>namekuseijin <(E-Mail Removed)> 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@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      09-28-2010
On Sep 28, 12:19*pm, Tim Bradshaw <(E-Mail Removed)> wrote:
>
> There are several existing systems which do this. *The HP48 (and
> descendants I expect) support "units" which are essentially dimensions.
> *I don't remember if it signals errors for incoherent dimensions. *
> Mathematica also has some units support, and it definitely does not
> indicate an error: "1 Inch + 1 Second" is fine. *There are probably
> lots of other systems which do similar things.
>

The problem is that if you allow expressions rather than terms then
the experssions can get arbitrarily complex. sqrt(1 inch + 1 Second),
for instance.

On the other hand sqrt(4 inches^2) is quite well defined. The question
is whether to allow sqrt(1 inch). It means using rationals rather than
integers for unit superscripts.

(You can argue that you can get things like km^9s^-9g^3 even in a
simple units system. The difference is that these won't occur very
often in real programs, just when people are messing sbout with the
system, and we don't need to make messing about efficient or easy to
use).


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: "Strong typing vs. strong testing" namekuseijin Python 229 10-29-2010 09:02 AM
Strong typing for user controls =?Utf-8?B?Unlhbg==?= ASP .Net 5 01-16-2006 02:00 PM
Compilation fails when a windows form user control is assigned a strong name but it refers to an activex control which does not have strong name ashish_gokhale ASP .Net Web Controls 0 05-05-2005 01:38 PM
strong/weak typing and pointers Gabriel Zachmann Python 102 11-13-2004 01:45 AM
Strong/static typing in Java and C/C++ Digital Puer Java 27 09-12-2003 11:05 PM



Advertisments