"Strong typing vs. strong testing"

[RG]

In article 
<07f75df3-778d-4e3d-8aa0-fbd4bd108a57 at k22g2000prb.googlegroups.com>,
 Squeamizh <squeamz 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.

> We are all aware that there is no perfect software development process
> or tool set.  I'm interested in minimizing the number of problems I
> run into during development, and the number of bugs that are in the
> finished product.  My opinion is that static typed languages are
> better at this for large projects, for the reasons I stated in my
> previous post.

More power to you.  What are you doing here on cll then?

rg