3 ms·

>> Real world JavaScript is inconsistent, messy, and complicated JavaScript is consistent. Expressive languages such as JS are consistent in their permissivene

>> Real world JavaScript is inconsistent, messy, and complicated JavaScript is consistent. Expressive languages such as JS are consistent in their permissiveness. It doesn't stop developers from doing irrational things like comparing objects with numbers just like TypeScript doesn't stop developers from writing all other kinds of flawed logic. TypeScript basically only protects code from typos. The worst bugs I see in production systems are almost never caused by typos or by comparing incompatible types; usually they're caused by issues in the flow and manipulation of data; for example the same instance is being modified in two different parts of the code without the other part of the code being aware of it; or in the case of pure FP a function is using outdated instances because a change in the underlying data source did not propagate through correctly, etc... TypeScript is to a software developer what a spell checker is to a book author; it's convenient but once you run the final product past your editor-in-chief (whose analogy in the software world are unit/integration tests), the spell checking didn't actually add any value; at best it saved your editor-in-chief some time. It has no bearing at all on whether or not you'll get a Pulitzer Prize or a top ranking on Amazon. The downside to TypeScript is compile time and this is a significant drawback IMO because it slows down iteration time significantly. Time spent waiting for the build to finish is time that was not used to add new tests and new features. If you add up all the time that all developers on a project spent on waiting for the build (or lost their focus/train of thought as a result of waiting for the build to complete), how many extra unit or integration tests could have been written using that lost time? I think if you do the math, you will find that TypeScript is a net liability to the project.

lazarljubenovic 7y ago
You obviously never wrote TypeScript with strict flag turned on. It does control flow analysis, not just typo checking.
- cryptica 7y ago
  It does 'Control Flow Based Type Analysis' - Meaning that it only analyzes control flow for the sole purpose of determining type correctness which adds almost no value to the project. It doesn't prevent asynchronous control flow issues like for example; - Having two different parts of the code simultaneously (asynchronously) mutating the same object and causing data inconsistencies. - Your code starts a new asynchronous job (e.g. setInterval) in the background without killing the previous/existing job which was launched earlier. - An event listener was registered for the same event multiple times (e.g. from inside another event handler) without unregistering the previous listener and so every event now triggers multiple updates instead of one (and CPU usage keeps going up and you have a memory leak). - It doesn't tell you when you forgot to trigger a specific event - Or guarantee that two different parts of your code never run in parallel (asynchronously) when mutating some state. - Or that you missed an edge case and forgot to update a specific instance's property - Or that you were modifying the original instance of the object instead of merely a copy/clone of it as you assumed (or the opposite was necessary and you made the reverse assumption) Only a human brain can prevent those issues (and the list of such difficult issues is practically infinite; my list is a tiny sample) and those are the real issues in software development, not typos and auto-completion. Unless you're a web developer and your job only involves writing static webpages, you are likely to encounter much more difficult problems in your career besides not having automatic method name completion or typo prevention mechanisms. These problems I described above are complex enough that they make all the problems solved by TypeScript seem negligible. TypeScript's compile time delay becomes a bottleneck when trying to debug and resolve real difficult problems.
  - lazarljubenovic 7y ago
    > the list of such difficult issues is practically infinite Precisely. No matter how good a language is, you can always say "but it doesn't do xyz". If you want to replace the human brain by a language, then you're looking for AI, not a language. I understand what you mean, and I agree that these things are lacking from TypeScript. And I would love them. TypeScript is slowly adding more and more things, mitigating issues one by one, which were previously dissed off by developers with "it doesn't even do xyz". I have my job because my brain is smarter than TypeScript's compiler. And it does help me, because I know which things I don't have to think about anymore, based on how I write the code. So it does help me, because I think less about the set of problems which it DOES solve.

lazarljubenovic 7y ago

You obviously never wrote TypeScript with strict flag turned on. It does control flow analysis, not just typo checking.

cryptica 7y ago
It does 'Control Flow Based Type Analysis' - Meaning that it only analyzes control flow for the sole purpose of determining type correctness which adds almost no value to the project. It doesn't prevent asynchronous control flow issues like for example; - Having two different parts of the code simultaneously (asynchronously) mutating the same object and causing data inconsistencies. - Your code starts a new asynchronous job (e.g. setInterval) in the background without killing the previous/existing job which was launched earlier. - An event listener was registered for the same event multiple times (e.g. from inside another event handler) without unregistering the previous listener and so every event now triggers multiple updates instead of one (and CPU usage keeps going up and you have a memory leak). - It doesn't tell you when you forgot to trigger a specific event - Or guarantee that two different parts of your code never run in parallel (asynchronously) when mutating some state. - Or that you missed an edge case and forgot to update a specific instance's property - Or that you were modifying the original instance of the object instead of merely a copy/clone of it as you assumed (or the opposite was necessary and you made the reverse assumption) Only a human brain can prevent those issues (and the list of such difficult issues is practically infinite; my list is a tiny sample) and those are the real issues in software development, not typos and auto-completion. Unless you're a web developer and your job only involves writing static webpages, you are likely to encounter much more difficult problems in your career besides not having automatic method name completion or typo prevention mechanisms. These problems I described above are complex enough that they make all the problems solved by TypeScript seem negligible. TypeScript's compile time delay becomes a bottleneck when trying to debug and resolve real difficult problems.
- lazarljubenovic 7y ago
  > the list of such difficult issues is practically infinite Precisely. No matter how good a language is, you can always say "but it doesn't do xyz". If you want to replace the human brain by a language, then you're looking for AI, not a language. I understand what you mean, and I agree that these things are lacking from TypeScript. And I would love them. TypeScript is slowly adding more and more things, mitigating issues one by one, which were previously dissed off by developers with "it doesn't even do xyz". I have my job because my brain is smarter than TypeScript's compiler. And it does help me, because I know which things I don't have to think about anymore, based on how I write the code. So it does help me, because I think less about the set of problems which it DOES solve.