Python from Wise Guy's Viewpoint

[Ralph Becket]

myfirstname.mylastname at jpl.nasa.gov (Erann Gat) wrote in message news:<myfirstname.mylastname-2310030857350001 at 192.168.1.51>...
> 
> No.  The fallacy in this reasoning is that you assume that "type error"
> and "bug" are the same thing.  They are not.  Some bugs are not type
> errors, and some type errors are not bugs.  In the latter circumstance
> simply ignoring them can be exactly the right thing to do.

Just to be clear, I do not believe "bug" => "type error".  However, I do
claim that "type error" (in reachable code) => "bug".  If at some point
a program P' (in L') may eventually abort with an exception due to an
ill typed function application then I would insist that P' is buggy.

Here's the way I see it:
(1) type errors are extremely common;
(2) an expressive, statically checked type system (ESCTS) will identify 
  almost all of these errors at compile time;
(3) type errors flagged by a compiler for an ESCTS can pinpoint the source
  of the problem whereas ad hoc assertions in code will only identify a
  symptom of a type error;
(4) the programmer does not have to litter type assertions in a program
  written in a language with an ESCTS;
(5) an ESCTS provides optimization opportunities that would otherwise
  be unavailable to the compiler;
(6) there will be cases where the ESCTS requires one to code around a
  constraint that is hard/impossible to express in the ESCTS (the more
  expressive the type system, the smaller the set of such cases will be.)

The question is whether the benefits of (2), (3), (4) and (5) outweigh 
the occasional costs of (6).

-- Ralph