4 ms·

> I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can share anecdotal data about my own experience while refactorin

> I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can share anecdotal data about my own experience while refactoring: I do rely on the type checker (be it Flow or TypeScript) to alert me when my code changes have introduced type errors. Every time I run the type checker I realise that it would have taken me ages to read through my code and hunt down the type mismatches that might have been introduced. I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript [0] > TypeScript ... does not Sure. It's not perfect. It's not Haskell, or PureScript, or Scala, or OCaml. But it does protect you from some of the errors. Protection from some of the errors is better than no protection at all, that's my opinion. As a bonus point, type annotations serve as a living documentation of your code. > instead of down-voting, please try to convince me otherwise I did not downvote your post. I do not downvote other people's posts. [0] - https://twitter.com/remohjansen/status/1093815648566894594?lang=en https://twitter.com/remohjansen/status/1093815648566894594?l...

cryptica 6y ago
>> I can share anecdotal data about my own experience while refactoring I totally understand what you're talking about here. I know that TS feeling of being able to just tell the IDE to rename that variable or type anywhere and have that change automatically applied everywhere in the whole codebase. That said, my anecdotal data (having gone back and forth between first AS2 and AS3 for several years and then later between JS and TS multiple times over many years) is that good tests (especially integration tests) even with modest coverage are equally good at finding these sorts of bugs. If I forgot to rename a variable, my tests will fail straight away. Also, usually I try to keep my classes and functions localized with well defined responsibilities so that any specific kind of data does not need to traverse too many different files; that makes refactoring a lot easier. IMO, not using TS puts more pressure on me to design code in this way and this design approach yields many other benefits. It takes encapsulation to another level. For example, I don't even believe in the idea of 'cross-cutting concerns' anymore (which is central to the Dependency Injection pattern). For me, the idea of cross-cutting concerns implies a violation of the separation of concern principle (a violation of the cross-cutting kind to be exact). There are almost always ways to avoid these in your code and doing so is always worth it if the programming environment allows it. >> I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript I did read that article when it came out but my point of view on this is that if mostly the same developers rewrite a project (even if they did so in the same language), I would expect at least 40% to 50% fewer bugs. I don't think TypeScript should get the credit there. The reality is that people learn from their mistakes so if they rewrite something, it's going to be better the next time round.

cryptica 6y ago

>> I can share anecdotal data about my own experience while refactoring I totally understand what you're talking about here. I know that TS feeling of being able to just tell the IDE to rename that variable or type anywhere and have that change automatically applied everywhere in the whole codebase. That said, my anecdotal data (having gone back and forth between first AS2 and AS3 for several years and then later between JS and TS multiple times over many years) is that good tests (especially integration tests) even with modest coverage are equally good at finding these sorts of bugs. If I forgot to rename a variable, my tests will fail straight away. Also, usually I try to keep my classes and functions localized with well defined responsibilities so that any specific kind of data does not need to traverse too many different files; that makes refactoring a lot easier. IMO, not using TS puts more pressure on me to design code in this way and this design approach yields many other benefits. It takes encapsulation to another level. For example, I don't even believe in the idea of 'cross-cutting concerns' anymore (which is central to the Dependency Injection pattern). For me, the idea of cross-cutting concerns implies a violation of the separation of concern principle (a violation of the cross-cutting kind to be exact). There are almost always ways to avoid these in your code and doing so is always worth it if the programming environment allows it. >> I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript I did read that article when it came out but my point of view on this is that if mostly the same developers rewrite a project (even if they did so in the same language), I would expect at least 40% to 50% fewer bugs. I don't think TypeScript should get the credit there. The reality is that people learn from their mistakes so if they rewrite something, it's going to be better the next time round.