"Strong typing vs. strong testing"

[Squeamizh]

On Sep 29, 3:14 pm, RG <rNOSPA... at flownet.com> wrote:
> In article
> <07f75df3-778d-4e3d-8aa0-fbd4bd108... at k22g2000prb.googlegroups.com>,
>
>
>
>
>
>  Squeamizh <sque... at hotmail.com> wrote:
> > On Sep 29, 3:02 pm, RG <rNOSPA... at flownet.com> wrote:
> > > In article
> > > <996bd4e6-37ff-4a55-8db5-6e7574fbd... at k22g2000prb.googlegroups.com>,
>
> > >  Squeamizh <sque... at hotmail.com> wrote:
> > > > On Sep 27, 10:46 am, namekuseijin <namekusei... at gmail.com> wrote:
> > > > > On 27 set, 05:46, TheFlyingDutchman <zzbba... at aol.com> wrote:
>
> > > > > > On Sep 27, 12:58 am, p... at informatimago.com (Pascal J. Bourguignon)
> > > > > > wrote:
> > > > > > > RG <rNOSPA... at flownet.com> writes:
> > > > > > > > In article
> > > > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b... at q16g2000prf.googlegroups.com
> > > > > > > > >,
> > > > > > > >  TheFlyingDutchman <zzbba... at aol.com> wrote:
>
> > > > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson" <Sc... at ergy.com> 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/-Hidequotedtext-
>
> > > > > > > - 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...
>
> > > > I disagree with your conclusion.  Sure, the data was textual when it
> > > > was initially read by the program, but that should only be relevant to
> > > > the input processing code.  The data is likely converted to some
> > > > internal representation immediately after it is read and validated,
> > > > and in a sanely-designed program, it maintains this representation
> > > > throughout its life time.  If the structure of some data needs to
> > > > change during development, the compiler of a statically-typed language
> > > > will automatically tell you about any client code that was not updated
> > > > to account for the change.  Dynamically typed languages do not provide
> > > > this assurance.
>
> > > This is a red herring.  You don't have to invoke run-time input to
> > > demonstrate bugs in a statically typed language that are not caught by
> > > the compiler.  For example:
>
> > > [ron at mighty:~]$ cat foo.c
> > > #include <stdio.h>
>
> > > int maximum(int a, int b) {
> > >   return (a > b ? a : b);
>
> > > }
>
> > > int foo(int x) { return 9223372036854775807+x; }
>
> > > int main () {
> > >   printf("%d\n", maximum(foo(1), 1));
> > >   return 0;}
>
> > > [ron at mighty:~]$ gcc -Wall foo.c
> > > [ron at mighty:~]$ ./a.out
> > > 1
>
> > > Even simple arithmetic is Turing-complete, so catching all type-related
> > > errors at compile time would entail solving the halting problem.
>
> > > rg
>
> > In short, static typing doesn't solve all conceivable problems.
>
> More specifically, the claim made above:
>
> > 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.
>
> is false.  And it is not necessary to invoke the vagaries of run-time
> input to demonstrate that it is false.

OK.  You finished your post with a reference to the halting problem,
which does not help to bolster any practical argument.  That is why I
summarized your post in the manner I did.

I agree that static typed languages do not prevent these types of
overflow errors.