> That is true but these errors are very easy to fix in any language.
No they're not. Language without static type checks end up with unit tests as an ersatz type check.
> The difficult and most important part of programming is getting the system design/structure/architecture right.
TypeScript is literally JavaScript with typing added. The underlying runtime is the exact same as whatever will be running your non-tranpiled-from-TypeScript JavaScript. The big changes for class syntax and enums are simply more tools in your belt but you do not have to use them. Any valid pure-JS design translates immediately to usage in TypeScript. It's strictly superior.
> Avoiding bad design is the real challenge of programming e.g. code paths are too long and traverse too many different files, it's not clear where objects are coming from in the code (bad DI), files are poorly named, directory structure makes no sense, exceptions are not thrown or handled correctly, logging is absent or not detailed enough, testing is focused on the least important functionality, validation logic for external data is wrong or hard to follow, system doesn't scale, components don't have clear separation of concerns, component abstractions are leaking lower level concepts into the higher level logic, access control layer has gaps, etc... Static typing doesnt add any value for any of these things.
> Static typing can help find class or function definitions and usages in the code more easily but only if the classes, functions and methods are poorly named to begin with (if classes and methods have good, highly relevant names, then they're always easy to find in any language).
Static typing isn't just grep on steroids. It catches entirely different classes of errors as well. Being able to immediately hop from a usage to its declaration is convenient, going in the other direction is amazing.
Refactoring the signature, not just body, of a function and feeling confident that all usages have been updated to reflect the change even before you run the app is empowering. It lowers the bar to change and allows your code to evolve more quickly.
> For a senior developer; design problems are the real hard problems. The rest is minor stuff and we shouldn't spend all our effort on those.
Exactly why analysis of problems that computers can solve better than humans (ex: "Is variable fooBarXyz in scope here?") should be deferred to computers.
>> No they're not. Language without static type checks end up with unit tests as an ersatz type check.
Not so. Checking that an object has a certain property or method is very different from checking if the object is of a specific type. Also, in any case, these kinds of assertions are best inside the test logic than inside the source code. Source code should be about raw logic - verification of the correctness of that logic is the job of tests. So dynamic typing has better separation of concerns.
No they're not. Language without static type checks end up with unit tests as an ersatz type check.
> The difficult and most important part of programming is getting the system design/structure/architecture right.
TypeScript is literally JavaScript with typing added. The underlying runtime is the exact same as whatever will be running your non-tranpiled-from-TypeScript JavaScript. The big changes for class syntax and enums are simply more tools in your belt but you do not have to use them. Any valid pure-JS design translates immediately to usage in TypeScript. It's strictly superior.
> Avoiding bad design is the real challenge of programming e.g. code paths are too long and traverse too many different files, it's not clear where objects are coming from in the code (bad DI), files are poorly named, directory structure makes no sense, exceptions are not thrown or handled correctly, logging is absent or not detailed enough, testing is focused on the least important functionality, validation logic for external data is wrong or hard to follow, system doesn't scale, components don't have clear separation of concerns, component abstractions are leaking lower level concepts into the higher level logic, access control layer has gaps, etc... Static typing doesnt add any value for any of these things.
> Static typing can help find class or function definitions and usages in the code more easily but only if the classes, functions and methods are poorly named to begin with (if classes and methods have good, highly relevant names, then they're always easy to find in any language).
Static typing isn't just grep on steroids. It catches entirely different classes of errors as well. Being able to immediately hop from a usage to its declaration is convenient, going in the other direction is amazing.
Refactoring the signature, not just body, of a function and feeling confident that all usages have been updated to reflect the change even before you run the app is empowering. It lowers the bar to change and allows your code to evolve more quickly.
> For a senior developer; design problems are the real hard problems. The rest is minor stuff and we shouldn't spend all our effort on those.
Exactly why analysis of problems that computers can solve better than humans (ex: "Is variable fooBarXyz in scope here?") should be deferred to computers.