Most people who have written python programs that takes longer than a couple of minutes to run remembers the pain. The pain of program crashing after x minutes/hours due to some trivial problems like typos in function names. You carefully fix the problem, and run it again, x minutes later yourself debugging another crash caused by another trivial problem...
What is the root problem? A lot of people who came from Java or C++ background will say: you need static type checking! True, static type checking would have caught a lot if not most of the mistakes I made in writing Python code. Although that is still a subset of the problems. Generally speaking, the pain comes from errors that are not detectable until runtime.
What are the solutions? For the ones that can be caught by type checking, the natural answer is "Let there be type checking!". That has been discussed extensively in the Python community in the past few years. See [1]Guido's essays on the topic. It's not introduced in Py3k. PEP 246 was a formal attempt to add optional type checking in Python but it was rejected in 2009 because "Something much better is about to happen. --- GvR". So for now the problem is not fundamentally addressed. One partial solution is static analysis. Pycheckerand Pylint are the two most popular ones. They catch a lot of errors that are usually caught by the compiler in static typing languages. They also catch coding style violations which in turn helps writing less error prone code. Still there are a lot errors goes undetected under these tools. For example:
def print_date(d):
d.strftiem("%Y-%m-%d")
What is the root problem? A lot of people who came from Java or C++ background will say: you need static type checking! True, static type checking would have caught a lot if not most of the mistakes I made in writing Python code. Although that is still a subset of the problems. Generally speaking, the pain comes from errors that are not detectable until runtime.
What are the solutions? For the ones that can be caught by type checking, the natural answer is "Let there be type checking!". That has been discussed extensively in the Python community in the past few years. See [1]Guido's essays on the topic. It's not introduced in Py3k. PEP 246 was a formal attempt to add optional type checking in Python but it was rejected in 2009 because "Something much better is about to happen. --- GvR". So for now the problem is not fundamentally addressed. One partial solution is static analysis. Pycheckerand Pylint are the two most popular ones. They catch a lot of errors that are usually caught by the compiler in static typing languages. They also catch coding style violations which in turn helps writing less error prone code. Still there are a lot errors goes undetected under these tools. For example:
def print_date(d):
d.strftiem("%Y-%m-%d")
Nobody knows anything about "d" and there is no way to find out "strftiem" is a typo until we run it. And the code may have executed for hours by the time this function is called.
Another partial solution is unit testing. Writing comprehensive unit tests can really iron out a lot of problems like this. But there are a few reasons unit testing is not enough to catch all the errors, but I won't go into that here.
Running static analysis frequently and writing unit tests can really save a lot of pains. But what next? There are still runtime errors falling through the cracks. Logging and debugger can help finding the problem, but you have to run the code again and again to iron out the all problems, which can be hours or days...
In the next post I will talk about a technique that I use to further reduce the pain.
[1] Guido's essays on static type checking
Another partial solution is unit testing. Writing comprehensive unit tests can really iron out a lot of problems like this. But there are a few reasons unit testing is not enough to catch all the errors, but I won't go into that here.
Running static analysis frequently and writing unit tests can really save a lot of pains. But what next? There are still runtime errors falling through the cracks. Logging and debugger can help finding the problem, but you have to run the code again and again to iron out the all problems, which can be hours or days...
In the next post I will talk about a technique that I use to further reduce the pain.
[1] Guido's essays on static type checking
1 comment:
I guess we have to remind ourselves where dynamic type came from in the first place - bypassing compile time type checking to resolve operation only till run time! So, that's the fundamental conflict. Strong type programming is a bit of out of date, but still has a very good reason to do so, avoiding downstream defects so to speak.
Post a Comment