Perspective on the Static vs. Dynamic Type Debate.

Rick DeNatale — Fri, 29 Jun 2007 08:49:00 -0400

My RSS reader uncovered a thought provoking paper by Chris Smith entitled “What To Know Before Debating Type Systems”. It clears up a lot of the confusion around the differences between static and dynamic type systems.

Much of the debate comes from people with limited exposure to both static and dynamic typing. He observes that:

Many programmers have used very poor statically typed languages.

Many programmers have used dynamically typed languages very poorly.

Many programmers have used very poor statically typed languages. Many programmers have used dynamically typed languages very poorly.

He then points out that although there is a good deal of overlap in the problems which can be solved by the two approaches, they are fundamentally different techniques. According to the paper:

A static type system is a mechanism by which a compiler examines source code and assigns labels (called “types”) to pieces of the syntax, and then uses them to infer something about the program’s behavior. A dynamic type system is a mechanism by which a compiler generates code to keep track of the sort of data (called its “type”) used by the program. The use of the same word “type” in each of these two systems is, of course, not entirely coincidental; yet it is best understood as having a sort of historical or generalized significance. Great confusion results from trying to find a world view in which “type” really means the same thing in both systems. It doesn’t.

Most of the popular languages with static type systems use static types to mechanically prove that a program is type-safe. Programs for which this can be proven are accepted, and others are rejected. The paper shows that for any such type-system there will be correct programs which cannot be proven correct and will be rejected.

Languages with dynamic type systems allow execution of programs without prior proof of ‘innocence.’ However, the presence of meta-information at run-time allows for fast-failure and better context for correction when errors do occur.

The type systems of most popular statically typed languages are rather limited in the properties which can be proven. Not all program bugs can be statically determined. Seemingly easy checks such as arrray index checking are actually quite difficult to express statically, most languages don’t check this statically. As Smith says, “this is an unusually hard problem to solve without making the languages that solve it unusable, but it’s a popular one to work on” as a research topic. Reading this paper has motivated me to learn more about Haskell to explore how easy or hard it is to push the notions of what can be statically checked.

It occurs to me that a language like C++ has a Napoleonic-code where you are ‘guilty until proven innocent’, but once you’ve gotten through the trial, you are free to go where you want and do what you want to do. However this means that if you are guilty of something which the type-system doesn’t discover, like an array bounds violation, your malfeasance might be undetected for some time, and then require sophisticated forensics to debug. In Ruby or Smalltalk, you are ‘innocent until proven guilty,’ but your actions are under a higher level of surveillance by the system.

Smith wraps up by re-framing the static vs. dynamic typing debate:

Static type systems prove properties of code, but it almost appears that Rice’s Theorem means we can’t prove anything of interest with a computer. If true, that would be an ironclad argument against static typing systems. Of course, it’s not true. However, it is very nearly true. What Rice’s Theorem says is that we can’t determine anything. (Often the word “decide” is used; they mean the same thing here.) It didn’t say we can’t prove anything. It’s an important distinction!

What this distinction means is that a static type system is a conservative estimate. If it accepts a program, then we know the program has the properties proven by that type checker. If it fails… then we don’t know anything. Possibly the program doesn’t have that property, or possibly the type checker just doesn’t know how to prove. Furthermore, there is an ironclad mathematical proof that a type checker of any interest at all is always conservative. Building a type checker that doesn’t reject any correct programs isn’t a challenger that may be solved some day; it’s impossible.

That, then, is the trade-off. We get assurance that the program is correct (in the properties checked by this type checker), but in turn we must reject some interesting programs. To continue the pattern, this is the diametric opposite of testing. With testing, we are assured that we’ll never fail a correct program. The trade-off is that for any program with an infinite number of possible inputs (in other words, any interesting program), a test suite may still accept programs that are not correct – even in just those properties that are tested.

He then poses eight questions to ponder when considering where and how to use static or dynamic typing in our programming tasks:

For what interesting properties of programs can we build static type systems?
How close can we bring those type systems to the unattainable ideal of never rejecting a correct program?
How easy can it be made to program in a language with such a static type system?
What is the cost associated with accidentally rejecting a correct computer program?
For what interesting properties of programs can we build test suites via dynamic typing?
How close can we bring those test suites to the unattainable ideal of never accepting a broken program?
How easy can it be made to write and execute test suites for programs?
What is the cost associated with accidentally accepting an incorrect computer program?

Talk Like A Duck: Perspective on the Static vs. Dynamic Type Debate.

Perspective on the Static vs. Dynamic Type Debate.