They pivoted a lot in that direction. Dart's strong mode is statically typed and sound and all that, except that you can say "dynamic" if you really need to.
Yes, so they realized that statically typed languages are superior years after creating the language, which is something we've learned and known for more than ten years.
Retrofitting a type system into a dynamically typed language has never been done successfully and it's unlikely Dart will invalidate that claim.
It's really a pity, Dart could have been a game changer.
I don't think they had any such "realization" about a superiority of static typing, especially as research indicates that there are tradeoffs between dynamic and static typing, not that there is superiority of one or the other model. Both Bracha and Felleisen tend to fall in the soft [1] or gradual [2] typing camp, after all. See, for example, Bracha's paper on pluggable type systems [3].
As for retrofitting a type system into a dynamically typed language, Dart had gradual typing from the beginning (with types being checked at runtime), so it's an entirely different beast from (say) Ruby or Python.
> especially as research indicates that there are tradeoffs between dynamic and static typing
Not really.
How come there are plenty of dynamically typed languages that are migrating toward optionally static typing but never the other way around?
Even Bracha himself, a very strong advocate of dynamically typed languages, has felt the need to work on Strongtalk and then later, to have Dart support optional static types.
Today, we have very good type inference engines and there is really no reason to ever want to use a dynamically typed language. This is the trend, this is the present and the future.
Javascript is going to be around for a while for legacy reasons but in a few years, we'll look back at dynamically typed languages with a fond "Yeah, it was a good idea at the time but we know better now" look.
> Type inference has its shares of issues once you're dealing with non-local type inference, subtype polymorphism or parametric polymorphism.
Just wanted to point out that actually, type inference works quite well with parametric polymorphism, like in ML. Even non-local type inference can work fine given other constraints, also like in ML.
1. Only for unconstrained parametric polymorphism. For constrained parametric polymorphism, ML requires functors (don't get me wrong, I think ML functors are brilliant, but they do require you to be rather explicit about your typing).
2. I wouldn't say that it's without problems even for unconstrained parametric polymorphism. Consider the value restriction [1] and the fact that if you add subtyping to the mix (as in OCaml), you're getting some really non-trivial issues (as Scala found out the hard way).
Retrofitting a type system into a dynamically typed language has never been done successfully and it's unlikely Dart will invalidate that claim.
It's really a pity, Dart could have been a game changer.