Dart and Types: Tennis without a net?

On November 2nd, 2011, Gilad Bracha gave a talk at Stanford University on Dart, Google’s new web programming language:

A Walk on the Dart Side: A Quick Tour of Dart

The talk is over an hour long but worth watching. The most controversial part of Gilad’s talk is about the role of types in Dart. Dart’s types are optional and treated as annotations, which do not affect runtime behavior. In other words, Dart is a dynamic language with optional types. Gilad acknowledges that you can write absurd code in Dart that still runs. But, he argues, you can also write nonsensical code in languages with mandatory types by using casts. Types do not guarantee correctness of code, he insists. Gilad adds that types are still useful for documenting code. Just remember that in Dart it does not matter whether you use types, or not. The compiled program will run the same.

Not enforcing any type consistency and treating types only as comments for documentation purposes may sound like playing tennis without a net and I am wondering: Why not? You would certainly see more interesting games!

To me optional types started making more sense after reading Dart’s Language Reference, which explains optional types in the context of two development modes:

Dart programs may be executed in one of two modes: production mode or checked mode. In production mode, static type annotations (13.1) have absolutely no effect on execution. In checked mode, assignments are dynamically checked, and certain violations of the type system raise exceptions at run time.

This sounds familiar. In fact this reminds me on how asserts work. You get errors in debug (checked) mode but asserts get stripped out in release (production) mode. If your code runs without any errors in debug mode you should be fine in release mode. I can see how you could do the same with types.

Let me try to translate this idea into an ActionScript example.

ActionScript is in a way a dynamic language with somewhat optional types. In general ActionScript encourages using types:

var sprite: Sprite = new Sprite();

The last line triggers a syntax error at compile time, because there is no “foo” method in Sprite:

1061: Call to a possibly undefined method foo through a 
reference with static type flash.display:Sprite.

Types can be optional as this example shows. Let’s assign sprite to an Object, which is by definition dynamic:

var sprite: Sprite = new Sprite();
var spriteObj : Object = sprite;

You won’t get a syntax error at compile time here. But at runtime you’ll get an error complaining about “foo” not being a Sprite method:

ReferenceError: Error #1069: Property foo not found on 
flash.display.Sprite and there is no default value.

Finally, what happens if you call a non-existing function on an Object?:

var obj : Object = new Object();

You won’t get a syntax error at compile time. But at runtime you’ll get this error:

TypeError: Error #1006: foo is not a function.

All three examples yield the same results in debug and release:

AS3 Debug Release
Syntax error #1061 Syntax error #1061
Runtime error #1069 Runtime error #1069
Runtime error #1006 Runtime error #1006


Now, if we applied Dart’s idea of checking types only in debug mode, we would end up with this interesting table (differences in red):

AS3 with “Dart rules” Debug Release
sprite.foo() Syntax error #1061 Runtime error #1006
spriteObj.foo() Runtime error #1069 Runtime error #1006
obj.foo() Runtime error #1006 Runtime error #1006


To be honest, I don’t think this is such a bad idea considering that throwing one error in all three cases in release mode would most likely open up new opportunities for performance improvements.

2 Responses to Dart and Types: Tennis without a net?

  1. Ganaraj says:

    What dart is suggesting is the ability to do both non typed and full typed constructs… To my understanding actionscript is exactly what dart is trying to be… what surprises me is why they havent adopted actionscript since that gets them a huge list of developer following already…

    In AS3.. you can do both

    var spr:Sprite = new Sprite();
    // now this doesnt allow you to do spr.foo();

    alternately you can do…

    var spr = new Sprite();

    this second case will only throw out errors during runtime.

    There is also another version for this..

    var spr:* = new Sprite();
    which is somewhat equivalent to saying I dont know its type right now..

    So actionscript IS a dynamic language for all arguments of dart.. or I am missing something here ..

    • Bernd Paradies says:

      Hello Ganaraj,

      what you are saying is correct: AS3 is a dynamic language. Google has a lot of resources and can afford to develop their own programming language in order to make it fit to the rest of their infrastructure. So in a way I understand why they are rolling their own Dart. (They would probably make their own milk, if they felt that something were missing, or not exactly the way it should taste in their opinion…)

      I personally like Dart but I don’t care too much about using dynamic features. In general, dynamic language expressions are really hard to analyze at compile time. As a result the cross-compiler has to resort to generating JavaScript, which the Closure compiler cannot optimize efficiently. In short, mobile device hardware might not be strong enough at this point to run JavaScript generated from ActionScript that uses a lot of dynamic language features. I am preparing a post in which I will explain my point of view in more detail.

      But what I do think is a great idea introduced by Dart is the notion of separating “developer mode” from “production mode”, which I loosely translated to “debug” and “release” builds. Dart’s idea of only enforcing certain language features for debug builds is fantastic and can be used productively for the AS3 to JS cross-compilation workflow. This post is more about digesting that idea and brainstorming of what that could mean for ActionScript.

      Best wishes,

      – Bernd