3 ms·

As someone that's extensively testing their application, I don't get the bug argument either. Sure some bugs are found during compile time. Actually, it's not b

As someone that's extensively testing their application, I don't get the bug argument either. Sure some bugs are found during compile time. Actually, it's not bugs the compiler finds. Rather it's inconsitencies between types and the rest of the code. But when testing properly, these should anyways be found later. Or am I missing something?

egeozcan 6y ago
It's a given that you can reduce the number of bugs in your app eventually, with any method/tool you can imagine, given enough time. That'd be still true if you were designing using sticks and stones on sand. Why not use another tool that helps you fix bugs easier, faster and sometimes spare you from writing them at all?
- timdaub 6y ago
  Why so aggressive? I asked a simple question out of interest. Again, I think there's a difference between bug and a coding error. A bug is a mismatch between a software's function and the user's expectation. And a typed-inferred error during compile time is just a hint that some code is incorrect. It may lead to a bug, but at the point of compilation, it's not a bug.
  - egeozcan 6y ago
    oh I didn't realize I sounded aggressive, sorry if it came off that way, cheers! I'd like to point out that if you agree that typescript prevents stuff that may lead to bugs, without getting into the semantics of what a bug is, you may agree that it's useful.
Jestar342 6y ago
Inconsistencies between types and rest of code _is_ bugs. I'm willing to bet my house that "TypeError: object doesn't support property or method" is the #1 bug in JavaScript's sphere.
- timdaub 6y ago
  100% agreed. But my point is that I usually find these types of bugs really easy when unit testing.
  - KronisLV 6y ago
    The assumption here is that there are unit tests that cover the areas containing these sorts of bugs. It can prove to be false because many projects don't have sufficiently good code coverage. Of course, it's also possible that there simply are no unit tests at all. In those circumstances, TypeScript might just result in less bugs overall. While one could argue that unit testing should be commonplace, reality doesn't always live up to that standard.
  - kungito 6y ago
    Real unit tests (not integration tests) are poor man's types. Usually when you have very small unit tests asserting inputs and outputs of methods you would simply assert those with types in more powerful languages
    - hajile 6y ago
      Haskell has pure functions everywhere and a much stronger typing system than TS, but unit testing is still considered important. Someone else will be changing that code later. Knowing (for example) that the parameter is a string will be zero help in knowing what is being done with that string. It also won't help know what edge cases the code was handling. Also, types give a false sense of security. A new project was integrated into an old website (one with legacy dependencies, but doing millions in transactions every day, so unchangeable). It broke and they couldn't figure out why. They had the TS types for functions, but an old framework (prototype or moo iirc) overrode js built-ins with incompatible versions. Later they got bitten again when that code changed the object types. If they'd been writing js, they would have written dynamic checks from the start, but it's easy to forget that once you compile, it's just js.
      - kungito 6y ago

egeozcan 6y ago

It's a given that you can reduce the number of bugs in your app eventually, with any method/tool you can imagine, given enough time. That'd be still true if you were designing using sticks and stones on sand. Why not use another tool that helps you fix bugs easier, faster and sometimes spare you from writing them at all?

timdaub 6y ago
Why so aggressive? I asked a simple question out of interest. Again, I think there's a difference between bug and a coding error. A bug is a mismatch between a software's function and the user's expectation. And a typed-inferred error during compile time is just a hint that some code is incorrect. It may lead to a bug, but at the point of compilation, it's not a bug.
- egeozcan 6y ago
  oh I didn't realize I sounded aggressive, sorry if it came off that way, cheers! I'd like to point out that if you agree that typescript prevents stuff that may lead to bugs, without getting into the semantics of what a bug is, you may agree that it's useful.

Jestar342 6y ago

Inconsistencies between types and rest of code _is_ bugs. I'm willing to bet my house that "TypeError: object doesn't support property or method" is the #1 bug in JavaScript's sphere.

timdaub 6y ago
100% agreed. But my point is that I usually find these types of bugs really easy when unit testing.
- KronisLV 6y ago
  The assumption here is that there are unit tests that cover the areas containing these sorts of bugs. It can prove to be false because many projects don't have sufficiently good code coverage. Of course, it's also possible that there simply are no unit tests at all. In those circumstances, TypeScript might just result in less bugs overall. While one could argue that unit testing should be commonplace, reality doesn't always live up to that standard.
- kungito 6y ago
  Real unit tests (not integration tests) are poor man's types. Usually when you have very small unit tests asserting inputs and outputs of methods you would simply assert those with types in more powerful languages
  - hajile 6y ago
    Haskell has pure functions everywhere and a much stronger typing system than TS, but unit testing is still considered important. Someone else will be changing that code later. Knowing (for example) that the parameter is a string will be zero help in knowing what is being done with that string. It also won't help know what edge cases the code was handling. Also, types give a false sense of security. A new project was integrated into an old website (one with legacy dependencies, but doing millions in transactions every day, so unchangeable). It broke and they couldn't figure out why. They had the TS types for functions, but an old framework (prototype or moo iirc) overrode js built-ins with incompatible versions. Later they got bitten again when that code changed the object types. If they'd been writing js, they would have written dynamic checks from the start, but it's easy to forget that once you compile, it's just js.
    - kungito 6y ago