I used to think that static type checking was a life-saving programming tool. I've been gradually changing my mind about this.

First, the first big program I wrote (many years back now), was written in Perl. It started out as a few scripts on a Web server, and over time grow into a full-fledged enterprise application for a finance company. It had a huge uptime (better than 99.999%), and had been used non-stop by several 100 people for years. Perl's weak typing was never an issue in writing that app, because I made very small changes to the system over several years (mainly because the system was constantly in use), and each small iteration brought to fore the biggest bugs during testing. So we could just fix those bugs right away, and type-mismatch bugs never found their way into the production system.

I think static typing is important when developers use tools that exploit them. With many IDEs, such as IDEA, I can just click on a variable that refers to a customer, and up pop all the methods I can invoke on that customer. I don't have to remember those methods, their parameters, or return types. I think it's a huge productivity booster, because I get to stay in one spot of the program and don't have to interrupt my flow looking at docs, etc (something Bruce had talked about in an earlier interview). I can just keep typing (pun intended).

Static typing becomes even more important when we access network-based resources. However, few systems provide a strongly typed network object model (Jini is one exception). With static typing, if I want to access a inventory management system, I can just write code that says, in effect, "OK, at this point just find an object that implements the Inventory type." Since I know the methods of that type, I can continue programming to that interface without having to know how someone implemented that inventory system. In reality, I might not even be able to find out the implementation, even if I wanted to, since we're talking about an object that comes across the network from some remote location. So a strongly typed system allows me to have the object's type be the only prior agreement with whoever implemented that Inventory object. On the other hand, progamming in an untyped network environment is often a complete nightmare - having remember protocol messages, message order and content, etc., are a very unproductive experience.

About Bruce's remarks on feeding real data into a program: I found that dynamic typing often breaks down during data loading. When I consume a text file, for instance, to feed someone's database into my program, I can use Python or Perl to read that text file. That Python program is going to parse the file, and give a variable that corresponds to, say, position 6 in the database file, which would, say, represent the sale price of an inventory item (e.g., a float). But a lot of databases out there are really often corrupt - position 6, for instance, might be blank, or represent some mistaken value. And that means that now *I* have write my own type checker. But I wouldn't have to do that if I could feed typed data into my program, i.e., a SaleItem. Because that object presumably conforms to all the contracts of what it means to be a SaleItem, I can take those guarantees for granted.

In fact, one of the biggest productivity boosters I came across lately is to put a strongly typed service layer on top of data sources that my program has to rely on.

I started using Python three weeks ago and I like it very much.
I tried to convince my colleagues to switch to Python, but the biggest problem is the "type checking" issue. Runtime type checking just scared them away.
Bruce Eckel's arguments are not so convincing to them(even not to me myself, and I like Python and Thinking in XXX).
Hope somebody could make a top ten list about why runtime type checking is GOOD(or not that BAD).

in Java we've also found out that we check things at both compile time and runtime
Strange to have a discussion of static vs. dynamic typing without mentioning that some type systems are much more powerful than others.

Haskell, Clean, OCaml (and potentially Nice) have type systems that are powerful enough to infer the types of functions and variables at compile time. The programmer simply doesn't need to do finger-typing. Let's not confuse the inadequacies of Java's type system with the capabilities of modern static typing.

Having looked at Python several times, the lack of runtime type checking has always been a show-stopper. All developers who have been in the business awhile know how difficult it is to develop robust, error-free code so the sooner bugs are caught the better. This idea of "wait until runtime" to catch errors is unacceptable. The rule of thumb is to catch as many errors, as early in the process, as possible. The "saving finger-typing" argument holds no weight when compared to catching bugs. For mission critical and safety-conscious systems, run-time type checking catches errors *before* serious consequences occur.

When productivity squares off against reliability, productivity should lose.

- Mike

I missed one point in the discussion about runtime vs. compiletime
type-checking and that is the self-documenting effect when I
explicitly specify the types I use.


I think this is much more communicating:


public Configuration getConfiguration(File file) throws IOException


than


def getConfiguration(file)