4 ms·

Imagine StaticScript: a JavaScript replacement with static types and no dynamic types, that is statically compiled and runs in your browser. What would it mean

Imagine StaticScript: a JavaScript replacement with static types and no dynamic types, that is statically compiled and runs in your browser. What would it mean for a StaticScript program to typecheck? It doesn't guarantee it will have no type errors. The model you typecheck against may be very different from the runtime truth. Browsers are different and provide different features, and will change after your program is compiled. Static type checking has a fundamental limitation: it happens too early. The more divergence between the static model and runtime truth, the less useful static typing is. This is a fundamental limitation, a place where static types can never supplant dynamic ones.

dragonwriter 9y ago
Dynamic types don't help you there either; if the runtime you test on behaves differently than the runtime used at the end, then suddenly your code blows up even if your tests are perfect. (In practice, of course, that's a bigger problem with interpreted than compiled languages, and, while that's a different divide than static/dynamic, it's correlated.) In any case, your example is one in which static languages are no worse than dynamic ones, so it is not one which prevents static languages from displacing dynamic of they are otherwise superior.
- ridiculous_fish 9y ago
  Dynamic types do help in this scenario! 1. When accesses are resolved dynamically, the failure mode is better controlled, e.g. exception instead of buffer overflow. 2. The failure is deferred to the point of execution (instead of e.g. load time). It is easy to omit features that depend on missing runtime support, just arrange for that code to not be executed. 3. Dynamic types allow you to interrogate which interfaces are supported, via reflection. We see all of this at work in (good) web sites. They gracefully degrade, they can dynamically choose implementations based on what the browser supports, and failures are JS exceptions instead of aborts. > In practice, of course, that's a bigger problem with interpreted than compiled languages Why does interpreted vs compiled matter? IMO the key distinction is dynamic linking vs static linking. When you link against code compiled after yours, the less assurance static types give, and the more important dynamic types become. > static languages are no worse than dynamic ones The proper comparison is between languages with dynamic types and languages without. TypeScript has both static and dynamic types. If it had no dynamic types, it would not be a viable JS replacement.
  - dragonwriter 9y ago
    If (as is typically, though not always, the case with dynamically typed languages) you are distributing source rather than compiled code, all the advantage of deferring until the runtime environment is known and making decisions based on what is actually available applies to statically typed languages, as well. Heck, even without that, dynamically linking support libraries specific to the renvironment has been a solution to this issue forever. Dynamic typing changes a little bit about how the solutions are implemented, but not the difficulty or even the basic logical approach.
  - jahewson 9y ago
    No they don’t. Everything you describe bone can be done in any language with reflection, such as Java, or even C++with RTTI. No need for any dynamic types in the type system.

dragonwriter 9y ago

Dynamic types don't help you there either; if the runtime you test on behaves differently than the runtime used at the end, then suddenly your code blows up even if your tests are perfect. (In practice, of course, that's a bigger problem with interpreted than compiled languages, and, while that's a different divide than static/dynamic, it's correlated.) In any case, your example is one in which static languages are no worse than dynamic ones, so it is not one which prevents static languages from displacing dynamic of they are otherwise superior.

ridiculous_fish 9y ago
Dynamic types do help in this scenario! 1. When accesses are resolved dynamically, the failure mode is better controlled, e.g. exception instead of buffer overflow. 2. The failure is deferred to the point of execution (instead of e.g. load time). It is easy to omit features that depend on missing runtime support, just arrange for that code to not be executed. 3. Dynamic types allow you to interrogate which interfaces are supported, via reflection. We see all of this at work in (good) web sites. They gracefully degrade, they can dynamically choose implementations based on what the browser supports, and failures are JS exceptions instead of aborts. > In practice, of course, that's a bigger problem with interpreted than compiled languages Why does interpreted vs compiled matter? IMO the key distinction is dynamic linking vs static linking. When you link against code compiled after yours, the less assurance static types give, and the more important dynamic types become. > static languages are no worse than dynamic ones The proper comparison is between languages with dynamic types and languages without. TypeScript has both static and dynamic types. If it had no dynamic types, it would not be a viable JS replacement.
- dragonwriter 9y ago
  If (as is typically, though not always, the case with dynamically typed languages) you are distributing source rather than compiled code, all the advantage of deferring until the runtime environment is known and making decisions based on what is actually available applies to statically typed languages, as well. Heck, even without that, dynamically linking support libraries specific to the renvironment has been a solution to this issue forever. Dynamic typing changes a little bit about how the solutions are implemented, but not the difficulty or even the basic logical approach.
- jahewson 9y ago
  No they don’t. Everything you describe bone can be done in any language with reflection, such as Java, or even C++with RTTI. No need for any dynamic types in the type system.