This post originated from an RSS feed registered with Python Buzz by Patrick Lioi. Original Post: Dynamic Typing Feed Title: Patrick Lioi on Python Feed URL: http://patrick.lioi.net/syndicate/Python/RSS2.xml Feed Description: Entries from the Python category of my personal site. Latest Python Buzz Posts Latest Python Buzz Posts by Patrick Lioi Latest Posts From Patrick Lioi on Python

In the Joel on Software forum, Dynamic Languages and Enterprise Applications has a discussion on dynamic languages with test-driven development versus static languages with compile-time error checking. The python (et al) proponents echo Bruce Eckel's Strong Typing vs. Strong Testing, while everyone else raises fair counter arguments. In the discussion, Philo argues:

...you're saying that test suites absolve the issue of data typing. I *guessing* that that means that a thorough test will point out places where dynamic typing got you in trouble?

But then what? Don't you have to *then* write the "more code"? If the test suite points out an error where you're assuming a date but the user entered an integer, how else do you deal with the error but by writing more code?

The problem with this argument is that programmers who use statically-typed languages are so used to having to declare types everywhere that they don't realize they are writing type-checking code. For an example, just look at the "Hello, world!" in Python & Java, Side by Side Comparison. Better still, look at the example immediately below that: because python is a dynamic language, we only have to be explicit in our types when necessary. The str() routine isn't declared as std::string str(int i). It is known to always return a string, and it can take in any object. We also know that we are sending it an integer on this occasion. Inside the for loop, we don't have to jump through hoops to convert between types, so we don't have to debug all that cruft just to accomplish a simple, common task. We don't have to write the "more code" that Philo suggests.

Now, to be fair, Philo is probably talking more about situations when you do genuinely misuse your types, and need to render a section of code more restrictive in what it will accept. So, in those situations, we can add "more code" to check the type of a variable, and possibly throw an exception in response to bad data. We handle our exceptions gracefully at runtime, and use the stacktraces to help debug during the developmenet phase. The "more code" is limited to those situations in which we need to be restrictive, which is significantly less often than all the cruft we take for granted in C++, Java, and the like.