Why Dart Types Are Optional and Unsound

Also, writing this:<p><pre><code> &#62; We don't want Dart to be a testbed for active programming &#62; languages research, but I think we're open to taking up &#62; ideas after they become well understood and unsurprising, &#62; a.k.a. a little bit boring. </code></pre> ... after saying this in the first paragraph:<p><pre><code> &#62; Dart uses types in a way that might seem strange. Most &#62; popular languages that offer a type system use it very &#62; differently. If you're familiar with types in Java, Haskell, &#62; Scala, or any statically typed language, you may wonder &#62; why on earth Dart makes the choices that it does. </code></pre> ... makes me wonder why on earth Dart makes the type system choices that it does ;)

<i>Don't you want strong typing for better performance?</i> <i>That's what I thought, too. The VM designers say that in practice, type guarantees really don't help them nearly as much as you might think, because type checks are not a major drain on performance.</i><p>No, but you can generate better code if you know <i>exactly</i> what types you're playing with ahead of time.<p>Say you have a function like this:<p><pre><code> void foo(SomeClass obj) { obj.bar(); } </code></pre> That could be compiled to just a straight 'jmp SomeClass::bar', whether you're compiling natively or to a VM.<p>If you don't have static types, the best code you can output is something along the lines of this:<p><pre><code> fn = lookup(obj, "bar") jmp fn </code></pre> Of course there are tricks that you can use to optimize this second case a bit that involve fancy static analysis, fancy JIT business, etc. but the point is that you will <i>never</i> generate better code than just a single jump to the right code, based on the types you know at compile time in a static language.

<p><pre><code> &#62; Correctness is easier to achieve for a VM that doesn't &#62; rely on static soundness guarantees, because you don't &#62; need the complexity of bytecode verification. </code></pre> I don't follow. You only need to verify bytecode if a), you have bytecode in the first place, and b), you assume the existence of a hostile compiler or other external bytecode source. Neither of these apply to Dart.

So what do types and type annotations actually <i>do</i> in Dart? I may have missed something obvious, but it looks like all the code samples given in the article will all pass static verification. Can someone give me an example of a code error that Dart will catch statically at compile time? My biggest confusion about Dart's type system (or at least its static one) is that it simply doesn't seem to do very much, so I wonder why it exists at all.

Pragmatically, typing is for tooling first, catching errors second, soundness a distant third.<p>My tastes run towards a C#-like language (<i>cough</i> Gosu): statically typed with inference, simple generics (covariance), proper function types to fill in most of the covariant holes, and a dynamic type escape hatch, just in case.<p>But of course they would.

<p><pre><code> mammal = cow; // [1] pig = mammal; // [2] Checks OK statically, but now pig holds a Cow. print(pig.oink()); // [3] NoSuchMethodException if we get this far. </code></pre> As far as I understand this means that no precondition can be encoded in the variable type. A function with a Pig argument can still cause a NoSuchMethodException exception because the argument can actually hold a Cow instance.

&#62;&#62; Don't you want strong typing for better performance?<p>&#62; That's what I thought, too. The VM designers say that in practice, type guarantees really don't help them nearly as much as you might think, because type checks are not a major drain on performance.<p>If this is the case, what is supposed to make Dart faster than JavaScript? It sounds like they will end up around the same speed.

One thing I don't get (not knowing much about type theory, and only having implemented a toy C++ subset compiler in a university class once):<p>Take a dynamically typed language, say, Python:<p>a = 1<p>a = "foo"<p>What disadvantage would you have if the language used type inference to set <i></i>a<i></i> to a static type of int when it encountered it?<p>a = 1<p>a = "foo" # compile/interpretation time error, "a is an int"<p>1) You get the speed/optimizations + tooling of static typing. 2) You get the dynamic typing benefit of not messing with type definitions etc.<p>Do people really do stuff like changing the type of a variable in normal Python use, anyway? Usually when I set something to something, I keep it in the same type.<p>Is there a disadvantage, besides having to initialize every variable upfront? Polymorphism/Generics are orthogonal to this, no?<p>Are there any languages that do it this way?

Yet another Dart post making no sense at all.