5 ms·

The title is, provocatively, "to type or not to type." The top of the article makes it clear that it really, really, really will answer whether we should type

The title is, provocatively, "to type or not to type." The top of the article makes it clear that it really, really, really will answer whether we should type or not type. From the top: >This is a terrific piece of work with immediate practical applications for many project teams. Is it worth the extra effort to add static type annotations to a JavaScript project? Should I use Facebook’s Flow or Microsoft’s TypeScript if so? Will they really catch bugs that would otherwise have made it to master? >TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code. In this comment I will address wherher this is really enough to deliver on that promise: Why is bugs a metric instead of bugs per programming hour, or hours of programming including fixing bugs, with or without typescript? Typescript adds types (and requires programmers to keep them in mind.) I think it's hardly controversial to claim that typed programs have a lower bug count because type errors are caught. It is also not controversial to claim that programming time is slowed down, because of the need to think of types. The question is: how much? If a programming language slowed everyone down by 5x but resulted in 75% fewer bugs, few people would choose it. Most people would choose bugs. If a programmer language was 100 times faster and only resulted in 5x as many bugs (so, instead of 100 times base rate, 500 times base rate) then I and practically everyone else would always choose it for almost everything. After all if it's 100x more productive you can take 80x productivity gain and sacrifice 20% of your programming wall time to spend on debugging. So real results around speed and bug count, as well as the insidiousness of bugs, are crucial. If the bug count were not increased in comparing a and b, but the second language had showstopping bugs that took 100x longer to find and fix, nobody would choose b. Bugs aren't just a number.

kod 9y ago
The article quantifies the time involved.
- yorwba 9y ago
  Specifically, Table II gives mean times of 231.4 s (Flow) resp. 306.8 (TypeScript). So if you spend on average more than 5 minutes debugging errors that static typing could have prevented, you're probably better off just writing the annotations.
lmm 9y ago
> It is also not controversial to claim that programming time is slowed down, because of the need to think of types. I'd dispute that. I think the types provide me a notation to think about something that I'd already want to think about, so I can actually program faster with them than without. (Very much agree with your overall point: what matters is not how many bugs we have but how much business value we deliver overall)
RyanCavanaugh 9y ago
> Typescript adds types (and requires programmers to keep them in mind.) Programs without TypeScript also require programmers to keep types in mind - it's just that those in those programs there's no way for a computer to verify that the programmer got the types right, and no unified way for a person to write down the types involved at any given point in their program.
- shakna 9y ago
  > Programs without TypeScript also require programmers to keep types in mind Not types, as such, but usually generics. JS is hard to talk about in this context because of it's weak typing and desire to type cast just about anything. So the comment may well be true for JS, but I wouldn't be certain of it, it certainly wasn't the case when I was working with CoffeeScript to avoid the common pitfalls of JS. But, for most dynamic languages, if you'll allow to stretch things a bit, I don't need to understand precisely what I'm feeding into the function. Instead of asking "is it a string?" or "is it a vector?" or anything else along those lines, usually I just need to ask "is it iterable?", if so, good enough for me. This can ease refactoring, when you need to change to a new type, because if the interface provides the same mechanism, you don't need to change anything. If it doesn't, then it may be possible to provide the interface, rather than modifying the function. --- Things can get more complex than this, however. Most people think of dynamic and weakly typed languages as the same. However, there are several strongly typed, dynamic languages. Often times they would not allow you to pass the wrong type to standard functions. Some dynamic languages have guards and contracts to ensure types - and some of those guards and contracts are... "compile time"... for lack of a better term. That gives you optional typing, that you can add as you feel the need to tighten up your code, whilst still allowing you to be as dynamic as you feel appropriate.
wiredearp 9y ago
> The question is: how much? The article over on https://games.greggman.com/game/dynamic-typing-static-typing/ https://games.greggman.com/game/dynamic-typing-static-typing... attempts to answer that and comes to a conclusion that is different from the study in question.
- logicallee 9y ago
  So the article you just linked ("Greggman") was interesting and began roughly along the lines of the questions I expressed in my comment. Sadly, JavaScript is not among the languages Greggman compared (didn't see it in the charts or on the page), let alone both JavaScript and a language that adds types to it. That's what we're really interested in, isn't it. And as the original article we're discussing ("To type or not to type") promises, that's what would have: >immediate practical applications for many project teams. Is it worth the extra effort to add static type annotations to a JavaScript project? Should I use Facebook’s Flow or Microsoft’s TypeScript if so? So if these languages had simply been included in Greggman, it really would have gotten at the essence of my questions. Unfortunately they weren't studied.
kvb 9y ago
I would certainly dispute that programming time is necessarily slowed down. Ironically, I find myself thinking much harder about types in a dynamic language, precisely because there's no compiler there to do the rote work for me. Lately I've been using pandas dataframes quite a bit, and the number of hours I've wasted due to problems with types is mindboggling.

kod 9y ago

The article quantifies the time involved.

yorwba 9y ago
Specifically, Table II gives mean times of 231.4 s (Flow) resp. 306.8 (TypeScript). So if you spend on average more than 5 minutes debugging errors that static typing could have prevented, you're probably better off just writing the annotations.

lmm 9y ago

> It is also not controversial to claim that programming time is slowed down, because of the need to think of types. I'd dispute that. I think the types provide me a notation to think about something that I'd already want to think about, so I can actually program faster with them than without. (Very much agree with your overall point: what matters is not how many bugs we have but how much business value we deliver overall)

RyanCavanaugh 9y ago

> Typescript adds types (and requires programmers to keep them in mind.) Programs without TypeScript also require programmers to keep types in mind - it's just that those in those programs there's no way for a computer to verify that the programmer got the types right, and no unified way for a person to write down the types involved at any given point in their program.

shakna 9y ago
> Programs without TypeScript also require programmers to keep types in mind Not types, as such, but usually generics. JS is hard to talk about in this context because of it's weak typing and desire to type cast just about anything. So the comment may well be true for JS, but I wouldn't be certain of it, it certainly wasn't the case when I was working with CoffeeScript to avoid the common pitfalls of JS. But, for most dynamic languages, if you'll allow to stretch things a bit, I don't need to understand precisely what I'm feeding into the function. Instead of asking "is it a string?" or "is it a vector?" or anything else along those lines, usually I just need to ask "is it iterable?", if so, good enough for me. This can ease refactoring, when you need to change to a new type, because if the interface provides the same mechanism, you don't need to change anything. If it doesn't, then it may be possible to provide the interface, rather than modifying the function. --- Things can get more complex than this, however. Most people think of dynamic and weakly typed languages as the same. However, there are several strongly typed, dynamic languages. Often times they would not allow you to pass the wrong type to standard functions. Some dynamic languages have guards and contracts to ensure types - and some of those guards and contracts are... "compile time"... for lack of a better term. That gives you optional typing, that you can add as you feel the need to tighten up your code, whilst still allowing you to be as dynamic as you feel appropriate.

wiredearp 9y ago

> The question is: how much? The article over on https://games.greggman.com/game/dynamic-typing-static-typing/ https://games.greggman.com/game/dynamic-typing-static-typing... attempts to answer that and comes to a conclusion that is different from the study in question.

logicallee 9y ago
So the article you just linked ("Greggman") was interesting and began roughly along the lines of the questions I expressed in my comment. Sadly, JavaScript is not among the languages Greggman compared (didn't see it in the charts or on the page), let alone both JavaScript and a language that adds types to it. That's what we're really interested in, isn't it. And as the original article we're discussing ("To type or not to type") promises, that's what would have: >immediate practical applications for many project teams. Is it worth the extra effort to add static type annotations to a JavaScript project? Should I use Facebook’s Flow or Microsoft’s TypeScript if so? So if these languages had simply been included in Greggman, it really would have gotten at the essence of my questions. Unfortunately they weren't studied.

kvb 9y ago

I would certainly dispute that programming time is necessarily slowed down. Ironically, I find myself thinking much harder about types in a dynamic language, precisely because there's no compiler there to do the rote work for me. Lately I've been using pandas dataframes quite a bit, and the number of hours I've wasted due to problems with types is mindboggling.