Paul Rubin a écrit : > greg <[EMAIL PROTECTED]> writes: >>> E.g. your program might pass its test and run properly for years >>> before some weird piece of input data causes some regexp to not quite >>> work. >> Then you get a bug report, you fix it, and you add a test >> for it so that particular bug can't happen again. > > Why on earth would anyone prefer taking a failure in the field over > having a static type check make that particular failure impossible?
Because static type checks impose a lot of arbitrary restrictions, boilerplate code etc, which tends to make code more complicated than it needs to be, which is a good way of introducing bugs that wouldn't have existed without static type checks. Depending on the application domain and some technical and non-technical constraints and requirements, it (often) happens that it's better to have the application deployed now with an occasional error message than to have it next year... And FWIW, when it comes to "weird piece of input data", statically typed languages are not specially better than dynamic ones... -- http://mail.python.org/mailman/listinfo/python-list
