Static typing VS. Unit tests
Okay. It’s kind of stupid to put static typing up against Unit tests. Even so, lots of people does so a lot of times in the discussion between dynamic and static programming languages.
Static typing provides you with a security net when it comes to typos. Alhough, it doesn’t give you any security against logical errors.
I’ll give an example
-
public static Foo{
-
private int stored;
-
public Foo(int bar){
-
self.stored=bar;
-
}
-
public void increment(){
-
self.stored +=1
-
}
-
}
compiles fine
-
public static Foo{
-
private int stored;
-
self.stored=bar;
-
}
-
public void increment(){
-
self.stored +=1;
-
}
-
}
Will give you an error already when you compile the class, because you attempt to store a String onto a property that will only accept integers. And if you use an IDE, it will notify about this error already when you write the code.
Now let’s do the same with python.
-
class Foo:
-
def __init__(this,bar):
-
this.stored=bar
-
def increment(this):
-
this.stored +=1
This looks perfectly fine, doesn’t it?
You’ll think so, and so will the IDE and the “compiler”.
Now execute this code as follows:
-
myfoo=Foo("shrubbery")
Still no errors.
Now, what happens when we call the increment method?
-
myfoo.increment()
BANG! now the code fails. What if your product could run for weeks before the increment method is called? You might have landmines in your code.
In this case static typing would have catched the error, but consider the following code:
-
public static Foo{
-
private int stored;
-
public Foo(int bar){
-
self.stored=bar;
-
}
-
public void increment(){
-
self.stored + 1;
-
}
-
}
This code will compile fine, and it’ll even run fine, but the result will not be as expected.
Writing programs in dynamic languages like Python without an extensive test suite is hazardous. Its even so hazardous that hardly anyone with some experience would even think about writing programs without it.
In the world of staticly typed languages programmers are lured into a false sense of security and may even never learn the habit of writing unit tests.
However, that being said. There is a lot of times I would love to have static type declaration in Python, or at least type hinting on method declarations. That would relieve us of all the libraries that has functions that takes “things” as arguments, and returns an enumerated list (tuple) of things. But I guess there are more that speaks against this than for it.
Tags: java, programming, python, rant, testing
This entry was posted
on Sunday, November 16th, 2008 at 18:19 and is filed under english, java, python.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Bookmark this
November 17th, 2008 at 20:24
Don’t forget isinstance. You can check types with isinstance(a, A) in python. I’m sure you could also define some decorator or metaclass magic to make the notation look more like a statically typed language, for instance giving a list of 2-tuples with names and types. I think I remember that Gnosis XML (http://freshmeat.net/projects/gnosisxml/) even has metaclasses for method/function overloading in python. You won’t get errors at “compile” time though, so you need the unit tests anyway to test it outside actual runs.
November 17th, 2008 at 20:39
Well… A good pythonista or rubyist wouldn’t use isinstance, but check if the object passed in possesses the properties used. This is sometimes hard though. And neither checking for properties nor using isinstance would solve the problem described above. The problem is that your code might run for years before this happens, and by then, you’ve started on another project, possibly even in another company, and even if not; you would possibly have a hard time figuring out what’s really wrong and how to solve it. I have a rather good example of this, which I think I’ll blog about soon
November 19th, 2008 at 14:06
[...] mentioned in the comments of a previous blog post I have a good example of simple, obvious bugs that could stay in your application for years, [...]