In article <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>, Squeamizh <sque...@hotmail.com> wrote:
> On Sep 29, 3:02 pm, RG <rnospa...@flownet.com> wrote: > > In article > > <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>, > > > > > > > > > > > > Squeamizh <sque...@hotmail.com> wrote: > > > On Sep 27, 10:46 am, namekuseijin <namekusei...@gmail.com> wrote: > > > > On 27 set, 05:46, TheFlyingDutchman <zzbba...@aol.com> wrote: > > > > > > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon) > > > > > wrote: > > > > > > RG <rnospa...@flownet.com> writes: > > > > > > > In article > > > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com > > > > > > > >, > > > > > > > TheFlyingDutchman <zzbba...@aol.com> wrote: > > > > > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson" <sc...@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: > > > > [...@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;} > > > > [...@mighty:~]$ gcc -Wall foo.c > > [...@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 -- http://mail.python.org/mailman/listinfo/python-list
