Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Type Checking and Techie Control
|
Posted: Jul 9, 2003 12:49 PM
|
|
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.
|
|
Previous Topic
