5 ms·

The Shocking Secret About Static Types

11 points by insulanian 10y ago

jdonaldson 10y ago
“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.
WorldMaker 10y ago
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 10y ago
  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 10y ago
    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." :)
dpc_pw 10y ago
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.

11 points by insulanian 10y ago

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

WorldMaker 10y ago

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 10y ago
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 10y ago
  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." :)

dpc_pw 10y ago

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.