My buddy Erik Meijer and Peter Drayton have written a paper on programming languages entitled Static Typing Where Possible, Dynamic Typing When Needed: The The End of the Cold War Between Programming Languages. The paper is meant to seek a middle ground between the constant flame wars over dynamically typed vs. statically typed programming language. The paper is pretty rough and definitely needs a bunch of work. Take the following excerpt from the first part of the paper

Static typing fanatics try to make us believe that “well-typed programs cannot go wrong”. While this certainly sounds impressive, it is a rather vacuous statement. Static type checking is a compile-time abstraction of the runtime behavior of your program, and hence it is necessarily only partially sound and incomplete. This means that programs can still go wrong because of properties that are not tracked by the type-checker, and that there are programs that while they cannot go wrong cannot be type-checked. The impulse for making static typing less partial and more complete causes type systems to become overly complicated and exotic as witnessed by concepts such as "phantom types" and "wobbly types"
In the
mother of all papers on scripting, John Ousterhout argues that statically typed systems programming languages make code less reusable, more verbose, not more safe, and less expressive than dynamically typed scripting languages. This argument is parroted literally by many proponents of dynamically typed scripting languages. We argue that this is a fallacy and falls into the same category as arguing that the essence of declarative programming is eliminating assignment. Or as John Hughes says, it is a logical impossibility to make a language more powerful by omitting features. Defending the fact that delaying all type-checking to runtime is a good thing, is playing ostrich tactics with the fact that errors should be caught as early in the development process as possible.

We are interesting in building data-intensive three-tiered enterprise applications. Perhaps surprisingly, dynamism is probably more important for data intensive programming than for any other area where people traditionally position dynamic languages and scripting. Currently, the vast majority of digital data is not fully structured, a common rule of thumb is less then 5 percent. In many cases, the structure of data is only statically known up to some point, for example, a comma separated file, a spreadsheet, an XML document, but lacks a schema that completely describes the instances that a program is working on. Even when the structure of data is statically known, people often generate queries dynamically based on runtime information, and thus the structure of the query results is statically unknown.

The comment about making programming languages more powerful by removing features being a logical impossibility seems rather bogus and seems out of place in an academic paper. Especially when one can consider the 'removed features' to be restrictions which limit the capabilities of the programming language.

I do like the fact that the paper tries to dissect the features of statically and dynamically typed languages that developers like instead of simply arguing dynamic vs. static as most discussions of this form take. I assume the purpose of this dissection is to see if one could build a programming language with the best of both worlds. From personal experience, I know Erik has been interested in this topic from his days.

Their list of features runs the gamut from type inference and coercive subtyping to lazy evaluation and prototype inheritence. Although the list is interesting I can't help but think that it seems to me that Erik and Peter already came to a conclusion and tried to fit the list of features included in the paper to that conclusion. This is mainly taken from the fact that a lot of the examples and features are taken from  instead of popular scripting languages.

This is definitely an interesting paper but I'd like to see more inclusion of dynamic languages like Ruby, Python and Smalltalk instead of a focus on C# variants like . The paper currently looks like it is making an argument for Cω 2.0 as opposed to real research on what the bridge between dynamic and static programming languages should be.


Monday, 18 July 2005 20:32:14 (GMT Daylight Time, UTC+01:00)
Overall, I liked the paper, but I think too many people are beating this horse to death. The issues surrounding static typing vs. dynamic typing is simply a religious matter amongst programmers. Programmers who believe in static typing will never cross over, and those who believe in dynamic typing will not either. It’s simply heretic to think about it, or even cross over. So that being said I would like to see a more objective study showing why the two groups think their religion is better that the other. Also I think their upbringing as programmers may reveal their affiliation to a particular typing mechanism. Debugging habits and individual programming styles may also reveal why people love one and hate the other.

Rant on.
Bosah C.
Tuesday, 19 July 2005 00:42:31 (GMT Daylight Time, UTC+01:00)
I haven't tried it yet, Boo's ducktyping is an interesting compromise.

Wednesday, 20 July 2005 23:53:17 (GMT Daylight Time, UTC+01:00)
Great stuff. Thanks for linking to this.

Personally I really like the type system of Haskell a lot. It uses type inference (like a lot of new languages today) and this goes a long way when you don't want to bother with typing but it allows you to declare the type of expressions if you want (and when the type cannot be infered).
Wednesday, 20 July 2005 23:55:58 (GMT Daylight Time, UTC+01:00)
I forgot to say that Boo looks good on paper. I haven't used it but reading through their material is a pure joy.
Comments are closed.