Static v Dynamic Types
- Static type systems perform type checking at compile-time, while dynamic type systems distinguish types at run-time. In our case JS is dynamic and Elm <3 is static.
- The For Static: detects bugs before execution, increases run-time efficiency, improves program understanding, and enables compiler optimization
- The For Dynamic: is well-suited for prototyping, since it allows a developer to quickly write code that works on a handful of examples without the cost of adding type annotations. THE COST OF ADDING TYPE ANNOTATIONS !??!
- Now this is pretty much where the agreement ends. This is not an attempt to
demonize the other, which is better argument, or sermon to get you to convert
to my side. The reason we started the intro off with a academic published
paper, is we want to look at this comparison head on. There is a reason we
have taken a liking to things like Elm or PureScript. There are pains in our
daily development lives, where the tools we have, just aren’t helping, or in
some case’s actively hindering use in being as productive as we can be.
To Type or Not to Type?
- The process basically looks like this.
- They find bugs that have been fixed in public source JS projects.
- They go back to the previous commit hash with the bug.
- They introduce both type systems, to see if adding specific type notation to the path of the known bug, will be caught in the compiler. And thus prompting the developer to fix it before it was every released.
- The goal is to:
“Thus, this experiment under-approximates static type systems’ positive impact on software quality, “
- It’s worth noting that introducing static typing to JS is not a new concept,
in fact, it appears to be a pretty well worn path. Beside TypeScript and Flow,
which you are likely aware of, here are a couple more:
- So what does it say when several of largest tech companies are actively working to mitigate the side effects of JS with static typing and optimized compiling ahead of the JIT? I think the answer lies in the finds of this paper. Now yes, it’s just one small paper, and yes it echo’s our feelings already, well my feelings, and if you’re listening, pretty good change yours too.
So with that disclaimer….
The core contribution of this work is to quantify the public bugs that static type systems detect and could have prevented: 15% for both Flow 0.30 and TypeScript 2.0, on average. Our experimentation artefacts are available at: http://ttendency.cs.ucl.ac.uk/projects/type_study/.
- HOLY COW that is a pretty big percentage!
- Bad actors eliminated up by static types:
- Type mismatches, possibly hidden by JS coercion
- Undefined properties
- method accesses
- Undeclared variables
- Type shim: a set of type bindings for the free identifiers. You can think of it as a interface T.
- Important for thought some of the pain, that we as JS developers run up
against is beyond just types. Consider the following excert:
complicated module dependencies, the lack of annotated interfaces for some modules, tangled fixes that prevented us from isolating the region of interest, and the general difficulty of program comprehension.
- man, does that not sound like most JS projects you’ve worked on? I think this, this is the why I am so drawn to Elm, and have such buy-in to the Elm Architecture.
- And if that wasn’t enough for convincing, this study was done during the
update from TypeScript 1.8 -> 2.0 which introduced strict null checking.
We reviewed our corpus and found that 22 bugs, an increase of 58%, are detectable under TypeScript 2.0 but not under TypeScript 1.8. This result decisively and quantitatively demonstrates the value of TypeScript 2.0’s strict null checking.
Free as in Beer
|Token Tax Mean||Token Tax Median||Time Tax (s) Mean||Time Tax (s) Median|
handling modules was the most time-consuming aspect of annotating buggy versions
* There is a whole section on related work, threats to validity, I encourage you to read this article, and see what points you agree with our disagree with.
- Also located Here
- Clousure Compiler
- Flow and static type checking
- What to know before debating types
- You Don’t Know JS: Types & Grammarcjdjfj