
The Shocking Secret About Static Types - insulanian
https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.h2mg39u32
======
dpc_pw
The whole "bug-density by language" thing is just pointless for sooo many
reasons. The first one being the lower-level statically typed languages are
used to write more complex, widely used and mission-critical software. The
second is: eg. C++ is just a bad programming language, and static typing is
not going to save your bugcount.

------
WorldMaker
With regards to TypeScript at least:

«I worry about building up a large codebase using TypeScript, only to have the
ECMAScript spec introduce conflicting keywords and type features such as
`interface` and `implements`.»

These two examples seem particularly poor to me: `interface` has a fairly
standard meaning across the OOP side of the algol-syntax family (C++, Java,
C#, et al), and it would take a very interesting spec proposal to take that
keyword in a very different direction from how Typescript currently uses it.
(`implements` maybe less so, but there Typescript uses `implements` in very
specific contexts and Typescript has the benefit of type information to narrow
between existing uses of `implements` and some theoretical crazy new language
feature yet to be proposed.)

It's interesting to note too that `interface` and `implements` have been
reserved keywords since ES 2. It should be unsurprising that the "lost" ES 4
usage of `interface` and `implements` looks very, very similar to how
Typescript uses those keywords (as can be seen in 'real life' in ActionScript
3).

«The advantage of using the TypeScript compiler is that even if that happens,
you can just compile away the differences. The disadvantage is that you’re not
really writing standard JavaScript anymore. I predict that TypeScript won’t be
able to maintain its position as a superset of JavaScript. I believe it will
inevitably diverge over the years.»

Thus far the Typescript team has done an admirable job at pivoting to meet the
ES spec, even as the spec has changed. (Examples can be seen in things like
the module import syntax and "inner modules" now "namespaces".) Thus far TS
has been good to add deprecation warnings of the non-standard ways of doing
things and TS benefits from being a compiler here in that you can ratchet up
the strictness checks including making sure you aren't using non-standard
features. Presumably such checks will also keep up and pivot with spec
changes.

Beyond that, I think it is easy to argue that Typescript is approaching the
critical mass in developer usage and mindset that Typescript will as much be
helping to guide future specs as it will have to try to keep up with them.

Especially in the current "Stage Progression" system that ECMA's TC39 has
moved to, Typescript (and fellow tools like Babel) is a bellwether "early
stage" laboratory to test and verify early proposals long before they become
specifications.

~~~
karmakaze
If and when TypeScript and ESn diverge, my wish is that the dominant browsers
choose to implement the better based on merit while factoring in usage and not
blindly based on name alone.

~~~
WorldMaker
Which is partly why I suspect we'll see much more convergence over time than
divergence. The two biggest browser makers (Microsoft and Google) both have
increasingly large Typescript teams. ("The spec changes are coming from inside
the house." :)

------
jdonaldson

      “The data indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic; and that managed memory usage is better than unmanaged.”
    
      Now that’s more like it! Except:
    
      “While these relationships are statistically significant, the effects are quite small.” [Emphasis added.]
    
      In fact, I’m not aware of any empirical evidence that static types have a strong impact on bug density.
    

Absence of proof is not proof of absence. There are multiple confounding
factors when comparing languages in this fashion. (To name at least one,
consider the big difference in use cases and applications with javascript vs.
C). Even with confounding factors, static typing still has an edge in the
analysis.

It's disappointing to see folks fall into traps of confirmation bias. Nobody
is saying that dynamic languages don't have their place. It's fine if dynamic
languages and their domains are all that someone cares about. However, don't
assume for a second that learning a statically typed language is a waste of
time. In fact, I would argue that it lets the individual tackle much more
complex projects. One side effect of this possibility is that the individual
will cause more complex bugs that can't be detected through static type
analysis. This isn't a negative though, it's just the new reality.

