[rbehrends]

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.

[1] http://wiki.c2.com/?SoftTyping

[2] https://en.wikipedia.org/wiki/Gradual_typing

[3] http://bracha.org/pluggableTypesPosition.pdf

[hota_mazi]

> 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.

[rbehrends]

> Not really.

Can you provide support for this claim? Existing research [1] seems to indicate that it isn't clear-cut at all.

> Today, we have very good type inference engines and there is really no reason to ever want to use a dynamically typed language.

Type inference has its shares of issues once you're dealing with non-local type inference, subtype polymorphism or parametric polymorphism.

[1] https://danluu.com/empirical-pl/

[wtetzner]

> 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.

[rbehrends]

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).

[1] http://mlton.org/ValueRestriction

[wtetzner]

Yes, subtyping makes everything more complicated. I think there was a paper about type inference for subtyping posted on HN a while back, but I don't remember much about it.