Skip to content

Instantly share code, notes, and snippets.

@thezerobit
Created July 19, 2013 22:12
Show Gist options
  • Save thezerobit/6042715 to your computer and use it in GitHub Desktop.
Save thezerobit/6042715 to your computer and use it in GitHub Desktop.
dynamic typing > static typing ?
Is a dynamically typed language w/ optional type annotations and type-inferring compiler strictly better than a statically typed language with type inference?
0. Both languages have "strong" typing in the sense that values have definite types.
1. Any expression that would trigger an obvious type error (eg. calling string-concatenation function with 2 numeric constants) in compilation in the static lang, would trigger a similar warning in the dynamic language. The dynamic language would allow the program to actually compile and run and (presumably) fail at runtime, but would give you the option to fail compilation on these types of warnings (--fail-on-type-error).
2. Any expression that cannot be properly type inferred would fail compilation for the statically typed language but would succeed (with a lesser warning) for the dynamic language with the option to fail compilation for this type of warning, also (--fail-on-unknown-type).
3. For identical code, there is no reason that the dynamically typed language would need to produce less efficient machine code than the statically typed language. In fact, they should always produce identical machine code. It is useless to compare the performance of ambiguously typed code, since that *only* compiles for the dynamically typed language. If you want the performance of that code to be better on than it is already, you can type-annotate it.
I submit that these languages are equivalent, with the caveat that --fail-on-type-error and --fail-on-unknown-type are always enabled for the compiler for the static version of the language.
If this is the case, isn't the dynamically typed language strictly better than the statically typed version, in that it allows you to build ambiguously typed code when necessary (when the type inferencer isn't good enough to prove that your code is well-typed)? If you like, you can use the unambiguous subset of the language, or start a project with just --fail-on-type-error enabled, and then after everything is working, add --fail-on-unknown-type forcing you to go through and annotate all the ambiguously typed sections.
There is no perfect type inferencer (it's probably NP-hard for a sufficiently advanced language) so I cannot see how the statically typed language is nothing more than a weaker subset of the dynamically typed language.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment