|
|
|
Sponsored Link •
|
Summary
Musings on the reasons people like me prefer static type checking for building systems.
|
Advertisement
|
In his weblog entry, Are Dynamic Languages Going to Replace Static Languages?, Uncle Bob Martin asks whether test-driven development makes static type checking redundant. This is an interesting question, one I've heard pop up a lot the past couple years. This debate is often phrased in either-or terms, but I would like to steer the discussion more towards asking which kinds of programming language are a good fit for which kind of programming problems.
The two languages I currently use most in my day to day work are Java and Python. I use them for different kinds of tasks. Even though I too have experienced that I am much faster at coding things up in Python than in Java, when I need to build a larger industrial strength system, I still prefer Java. Even though Java's static type checking does slow me down in the ways dynamic typing proponents claim, I feel the compiler is helping me. On the other hand, when I'm doing what I call scripts, I use Python. In those kind of situations I feel Java's static type checking and other restrictions would be in my way.
Let me give another example of my dual personality. When I'm logged in as root on the Linux server that served up this very page to you, the rm command is aliased to rm -i. That means that any time I try and remove a file while logged in as root, the rm command asks me whether I really want to delete each file I listed on the command line.
Now, I don't remember the last time I said no to one of those rm command prompts. I try to be very careful when logged in as root, and so I almost always mean what I say. Let's say I only say no once out of every 10,000 remove commands on average. This extra verification step slows me down every time I try to do a remove, and it only catches one error every 10,000 checks. And it doesn't catch every kind of error. I could, for example, still say yes and only later realize I really didn't want to delete that file after all. Is all that slow down worth it?
For me personally, when I'm logged in as root I prefer having rm ask me "Are you sure?" each time I use it. The extra step slows me down, giving me another chance to think about what I really want to do. And when I'm logged in as root, I feel like it's helping me.
On the other hand, when I'm simply logged in as bv, I don't alias the rm command. I do a lot more removing as bv than root, and as bv I have less power to remove really important files. So in that situation, I would feel the extra "Are you sure?" check would be in my way.
For me, the amount of checking I want, whether I'm writing software or removing files, depends on the situation.
The other thing that has been bothering me about the static/dynamic debate is all the focus on static compiler's catching of type errors as the reason for static type checking. I honestly don't think that the catching of static type errors is the main thing that attracts me to static languages for building systems. I think it is the formalism.
The languages we use, both human and programming, influence how we think. I like to think about building systems by partitioning them into APIs, and then designing the types and methods of those APIs in terms of contracts. And for me, I want to specify parameter types as part of the contract. In addition, I want to specify other restrictions on the input, such as a passed integer must be greater than or equal to zero. When I implement a method, I want to check to make sure the pre-conditions were met. I suspect I'll want to do that kind of thing when I'm building a system, no matter what language I'm using. It is how I think.
I try to be open minded. I see around me a lot of people whose opinions I respect excited about the productivity they feel building systems in a dynamically typed language. I want eventually to try building something more system-like, and less script-like, in a dynamic language, to see for myself. In the meantime, I just can't figure out what I would do about my cherished notion of designing systems in terms of designing contracts when using a dynamic language.
There's a whole installment of my interview with Guido van Rossum dealing with this question, Contracts in Python. Even after talking to Guido about it, I still don't think I quite get it, though I suspect what would be required is not that I figure out how to do contract-like design in Python. I suspect I would need to adopt a different way of thinking about building systems that fits the tool I'm using. Is it possible that this new way of thinking is what people find so freeing about building systems in a dynamic language?
Perhaps when I actually try building a system in a dynamic language I'll see the light. But perhaps I won't. I have observed that different programmers have different development personalities. It may just be that I am a contracts static type checking kind of guy.
Have an opinion? Readers have already posted 19 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Bill Venners adds a new entry to his weblog, subscribe to his RSS feed.
 | Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit