4 ms·

> incremental typechecking sounds small but isn’t. It pays huge dividends in developer productivity. As Dale notes, “Refactors that used to take weeks take days

by brylie 9y ago

> incremental typechecking sounds small but isn’t. It pays huge dividends in developer productivity. As Dale notes, “Refactors that used to take weeks take days, sometimes less..." Just out of curiosity, what is the basis of claims like that? What types of bugs does static typing prevent, and how pervasive are those bugs otherwise?

slackingoff2017 9y ago
I encourage you to convert some of your JS code. In my experience converting something like 10k lines, this is absolutely true. I convert using strictest compile rules + TsLint with most rules on. In those 10kish lines I found hundreds of potential bugs. I'm sure at least a third were real. The biggest culprits in our codebase were classic type errors and improper use of truthy/falsey. Adding types enables a ton of static analysis like identification of broken conditional statements. I found over 100 if statements that were always true/false or otherwise ineffective.
- tonyedgecombe 9y ago
  "I found over 100 if statements that were always true/false or otherwise ineffective." I'm not sure whether that shows how good Typescript is or how bad Javascript is.
  - slackingoff2017 9y ago
    Mostly the latter. With strict type checking enabled TsLint will warn you about impossible conditionals. You can go a step farther and force conditionals to return boolean true/false. This disables JavaScript's "truth/falsey" but prevents a whole class of errors caused by questionable design decisions... Like empty arrays being truthy.
badlucklottery 9y ago
From a refactoring perspective, typechecking makes the answer to the question "What is this change going to break?" much more obvious. Combine that with Typescript's IDE support and a lot of the usual dumb refactoring mistakes just don't happen so you can focus on the actual algorithmic problems emerging.
- Chyzwar 9y ago
  Your tests would catch breaking changes as well. In many typescript codebases (angular4) strict null checks is disabled befits are really minuscule. I am now doing an angular4 project and I do not feel any safer. If you want to have real static typing use Elm, Reason, BuckleScript. I do not trust MS. Tooling is already bad on anything other than VS Code. TypeScript development is slowing down from 2017.
  - badlucklottery 9y ago
    >Your tests would catch breaking changes as well. Absolutely. But it only tells me where the code failed, not necessarily where my structural assumptions first fell apart. So I then have to walk up the stack looking for that point. It's pretty mechanical to do but typescript does it for me. This also assumes you have solid test coverage which unfortunately isn't always true. Especially for code that is being refactored because it's becoming (or already is) unsustainable. >In many typescript codebases (angular4) strict null checks is disabled befits are really minuscule. I agree that --strictNullChecks is very useful if the codebase often assigns meaning to null/undefined but that's more of an overall design problem. I feel there's a lot of benefit outside of that but I'm generally all for explicitness in code so I might be biased. >I am now doing an angular4 project and I do not feel any safer. If it's greenfield development, you probably won't for now. The implicit type system is fresh in your mind and having to explicitly put it into code is just going to feel like it's slowing you down. I suspect the benefits will come later when someone who isn't intimately familiar is looking at it (could be a new team member, could be you after another project or a vacation). >If you want to have real static typing use Elm, Reason, BuckleScript. For sure. But the downside with these is the commitment required. Typescript is as low effort/commitment as you need it to be. And an experienced js dev can pick up the basics in an hour. >Tooling is already bad on anything other than VS Code. I've only really used it in webstorm (which also uses the typescript language service) and it's never been an issue.
  - earcaraxe 9y ago
    Look at mister test driven development over here. Hey everyone this guy writes unit tests. I'm joking here but I think that a lot of people ignore basics like writing unit tests, and that statically typed languages will break a lot more quickly and predictably for people who are lazier, since it enforces structure. However, I agree with you. Also I think that the people who really push for static typing are the kinds of people who already would write unit tests.

by brylie 9y ago

slackingoff2017 9y ago

I encourage you to convert some of your JS code. In my experience converting something like 10k lines, this is absolutely true. I convert using strictest compile rules + TsLint with most rules on. In those 10kish lines I found hundreds of potential bugs. I'm sure at least a third were real. The biggest culprits in our codebase were classic type errors and improper use of truthy/falsey. Adding types enables a ton of static analysis like identification of broken conditional statements. I found over 100 if statements that were always true/false or otherwise ineffective.

tonyedgecombe 9y ago
"I found over 100 if statements that were always true/false or otherwise ineffective." I'm not sure whether that shows how good Typescript is or how bad Javascript is.
- slackingoff2017 9y ago
  Mostly the latter. With strict type checking enabled TsLint will warn you about impossible conditionals. You can go a step farther and force conditionals to return boolean true/false. This disables JavaScript's "truth/falsey" but prevents a whole class of errors caused by questionable design decisions... Like empty arrays being truthy.

badlucklottery 9y ago

From a refactoring perspective, typechecking makes the answer to the question "What is this change going to break?" much more obvious. Combine that with Typescript's IDE support and a lot of the usual dumb refactoring mistakes just don't happen so you can focus on the actual algorithmic problems emerging.

Chyzwar 9y ago
Your tests would catch breaking changes as well. In many typescript codebases (angular4) strict null checks is disabled befits are really minuscule. I am now doing an angular4 project and I do not feel any safer. If you want to have real static typing use Elm, Reason, BuckleScript. I do not trust MS. Tooling is already bad on anything other than VS Code. TypeScript development is slowing down from 2017.
- badlucklottery 9y ago
  >Your tests would catch breaking changes as well. Absolutely. But it only tells me where the code failed, not necessarily where my structural assumptions first fell apart. So I then have to walk up the stack looking for that point. It's pretty mechanical to do but typescript does it for me. This also assumes you have solid test coverage which unfortunately isn't always true. Especially for code that is being refactored because it's becoming (or already is) unsustainable. >In many typescript codebases (angular4) strict null checks is disabled befits are really minuscule. I agree that --strictNullChecks is very useful if the codebase often assigns meaning to null/undefined but that's more of an overall design problem. I feel there's a lot of benefit outside of that but I'm generally all for explicitness in code so I might be biased. >I am now doing an angular4 project and I do not feel any safer. If it's greenfield development, you probably won't for now. The implicit type system is fresh in your mind and having to explicitly put it into code is just going to feel like it's slowing you down. I suspect the benefits will come later when someone who isn't intimately familiar is looking at it (could be a new team member, could be you after another project or a vacation). >If you want to have real static typing use Elm, Reason, BuckleScript. For sure. But the downside with these is the commitment required. Typescript is as low effort/commitment as you need it to be. And an experienced js dev can pick up the basics in an hour. >Tooling is already bad on anything other than VS Code. I've only really used it in webstorm (which also uses the typescript language service) and it's never been an issue.
- earcaraxe 9y ago
  Look at mister test driven development over here. Hey everyone this guy writes unit tests. I'm joking here but I think that a lot of people ignore basics like writing unit tests, and that statically typed languages will break a lot more quickly and predictably for people who are lazier, since it enforces structure. However, I agree with you. Also I think that the people who really push for static typing are the kinds of people who already would write unit tests.