5 ms·

> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). When I was playing w

> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). When I was playing with TS I converted a project and found no additional bugs. Type related bugs shouldn't be that common IMO (if they are and they're systemic (not like a one off) I would argue that there is an issue with the way you're architecting). Maybe TypeScript just isn't for me. I see its value but didn't find it high enough to continue using. I'm working on creating a .d.ts file for one of my open source libraries but I don't know that I'll use it beyond that anytime soon.

ng12 10y ago
Yeah, I think the bug-finding value is overblown. I advocate Typescript entirely for developer experience. It lets me codify complex domain objects and will catch the obviously wrong bugs while I'm developing -- things like passing arguments in the wrong order or passing an x to a function instead of a y. Not to mention with Webstorm or VSCode you have actually reliable autocomplete too.
chickenfries 10y ago
To me, the value is at design/write time, not in converting old code. Old code that already works correctly will not be made more correct with TS unless you have branches of code that haven't been tested (by you during development, in tests or by your users). Working TS just lets me catch type mismatches while I'm writing instead of after the whole build process has run and I've reloaded the browser.
- zip1234 10y ago
  Also don't forget refactoring. Try renaming a property with confidence in plain JS. In TS it is simple.
  - michaelmcmillan 10y ago
    No problem if you test your code, as you should.
    - recursive 10y ago
      Somehow, a failing test isn't quite as convenient as a reliable renaming operation.
      - michaelmcmillan 10y ago
        Granted, but a renaming option is just that. A test will not only provide confidence, but also tell you if the code contains a logical bug.
        throwaway9475 10y ago
        No, a test will tell you whether or not that test passes; it says nothing about the correctness of anything else. But at this point, you're doing the job of a typesystem.
        michaelmcmillan 10y ago
        > No, a test will tell you whether or not that test passes; it says nothing about the correctness of anything else. That is a tautology: Of course a failing test shows you that the test failed. However, your test suite is severely flawed if the type system makes it redundant.
        guscost 10y ago
        There's a whole class of type mismatch bugs, which can show up in one or more code paths of just about any practical program, and which can be eliminated by a type checker (instantly in your text editor if you set it up, or at compile time). If you are writing and maintaining tests for lots of these bugs, you should consider adding a type checker to do it for you. The difference in overhead between annotating a variable and writing a test is huge.
        michaelmcmillan 10y ago
        Which, again, proves my point: If your test suite can be reduced to a type checker you are doing it wrong. That being said, it does not mean that a type checker won't catch many of the same bugs tests do - but no more than a subset.

ng12 10y ago

Yeah, I think the bug-finding value is overblown. I advocate Typescript entirely for developer experience. It lets me codify complex domain objects and will catch the obviously wrong bugs while I'm developing -- things like passing arguments in the wrong order or passing an x to a function instead of a y. Not to mention with Webstorm or VSCode you have actually reliable autocomplete too.

chickenfries 10y ago

To me, the value is at design/write time, not in converting old code. Old code that already works correctly will not be made more correct with TS unless you have branches of code that haven't been tested (by you during development, in tests or by your users). Working TS just lets me catch type mismatches while I'm writing instead of after the whole build process has run and I've reloaded the browser.

zip1234 10y ago
Also don't forget refactoring. Try renaming a property with confidence in plain JS. In TS it is simple.
- michaelmcmillan 10y ago
  No problem if you test your code, as you should.
  - recursive 10y ago
    Somehow, a failing test isn't quite as convenient as a reliable renaming operation.
    - michaelmcmillan 10y ago
      Granted, but a renaming option is just that. A test will not only provide confidence, but also tell you if the code contains a logical bug.
      - throwaway9475 10y ago
        No, a test will tell you whether or not that test passes; it says nothing about the correctness of anything else. But at this point, you're doing the job of a typesystem.
        michaelmcmillan 10y ago
        > No, a test will tell you whether or not that test passes; it says nothing about the correctness of anything else. That is a tautology: Of course a failing test shows you that the test failed. However, your test suite is severely flawed if the type system makes it redundant.
        guscost 10y ago
        There's a whole class of type mismatch bugs, which can show up in one or more code paths of just about any practical program, and which can be eliminated by a type checker (instantly in your text editor if you set it up, or at compile time). If you are writing and maintaining tests for lots of these bugs, you should consider adding a type checker to do it for you. The difference in overhead between annotating a variable and writing a test is huge.
        michaelmcmillan 10y ago
        Which, again, proves my point: If your test suite can be reduced to a type checker you are doing it wrong. That being said, it does not mean that a type checker won't catch many of the same bugs tests do - but no more than a subset.