program surgery vs. type safety
Alex Martelli
aleax at aleax.it
Mon Nov 17 10:17:07 EST 2003
More information about the Python-list mailing list
Mon Nov 17 10:17:07 EST 2003
- Previous message (by thread): program surgery vs. type safety
- Next message (by thread): module compile scope problem
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
dman at dman13.dyndns.org wrote: > On 14 Nov 2003 04:17:08 -0800, Jeremy Fincher wrote: >> Alex Martelli <aleax at aleax.it> wrote in message >> news:<QAOsb.21403$hV.779611 at news2.tin.it>... >>> Sure, >>> "tests can only show the _presence_ of errors, not their >>> _absence_". But so can static, compiler-enforced typing -- it >>> can show the presence of some errors, but never the absence of >>> others ("oops I meant a+b, not a-b"! and the like...). >> >> But it *does* show the absence of type errors, > > Not all the time. Casting (a la C, C++, Java) allows the programmer > to say "silly compiler, you don't know what you're saying" (usually, > it also converts int<->float and such, but apart from that). That > results in a runtime type error the compiler didn't detect. A Java > runtime will detect that later, but C and C++ will just behave wrong. Jeremy was arguing for a _GOOD_ static typing system, as in ML or Haskell, not the travesty thereof found in those other languages. I do not think I've seen anybody defending the "staticoid almost-typing" approach in this thread. Alex
- Previous message (by thread): program surgery vs. type safety
- Next message (by thread): module compile scope problem
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list