5 ms·

Can be said about regular modern JS as well. Whether your project has types or not is not alone going to determine the success of the project.

by sgt 4y ago

zarzavat 4y ago
I personally can’t agree with that. TS catches me writing numerous bugs a day, the structural typing plus static analysis is a superb combination. If your code base is in JS without types, you probably have many bugs, you just don’t know about them. Especially around undefined/null handling. TypeScript also allows me to refactor fearlessly, which substantially improves the quality of my code as I can do mini-rewrites without worrying about breaking interfaces.
- adamddev1 4y ago
  Nothing as satisfying as quickly adjusting all the red squiggly lines after a big refactor and then seeing everything run perfectly again.
- xodeus 4y ago
  > TS catches me writing numerous bugs a day I see this sentiment a lot but I honestly can't think of any non-trivial bugs that TS has caught for me. 99% of the bugs it catches I would see 1 second later when my page hot reloads and crashes.
  - vsnf 4y ago
    That’s the beauty though, isn’t it. Most bugs are trivial. I appreciate typescript getting the trivial bugs right more often than I’d trust myself to do so.
    - dleslie 4y ago
      Right? The argument that static/strict typing mostly catches trivial bugs isn't an argument against the value of that language, and yet people seem to think it is!
      - alrlroipsp 4y ago
        Let them fight windmills while we have a good time.
      - DogLover_ 4y ago
        I have to disagree. Adding the types will increase the number of the characters/lines of code which with a 80-char formatter limit can make functions look almost gibberish at a glance. Do that on a whole codebase and it becomes a mess to look at.
        eyelidlessness 4y ago
        And I have to disagree in turn. Those additional characters and lines of code are documentation, and turn gibberish into not only human-readable clarity about the code you’re reading, but a machine-traversable dependency graph as well.
        hbrn 4y ago
        The problem is that they are forced documentation. You can't choose to skip it after you became familiar with it.
        eyelidlessness 4y ago
        That sounds like a VSCode extension I could write on a Saturday morning but whatever.
        _0w8t 4y ago
        The verbosity of TypeScript types can be attributed to poor choice of syntax and names that became obvious retrospectively. Still even with TypeScript if types makes your functions ugly, then it shows the complexity of the code. Often it also suggests sensible refactoring that without types would not be apparent.
        DogLover_ 4y ago
  - fifticon 4y ago
    well I can, I wrote a year-long js project that I abandoned as refactorings gradually turned into eternal bug-fests. I started from scratch in typescript, and the project is now 3x the dead project, with none of the bugs. and refactorings have become painless, with the compiler tools and editor telling me what I must fix up. There may be a special breed of programmers who need no such help, but I have yet to meet them in my 32+y long professional programming career :-)
    - mixmastamyk 4y ago
      You still have bugs, you just haven't found them yet. When strict typing is not available you adjust and use other tooling and tests. Of course with a big, venerable project the balance changes drastically. But an experienced single-person project should be doable with javascript for a long while and may even get to MVP faster by focusing on things that are essential.
      - CodeWriter23 4y ago
        I’ve been coding professionally for 39 years. ts seemed very strange to me at first. Only even started using it because I had to do some customization in NetSuite and some third party type and build support in ts made comprehensible the typically-stilted and insane NetSuite js required by SuiteScript. Now I’m addicted to it. Specifically the lightweight and easy to use _interface_ directive feeds my practice of self-documenting code with good doc and reusable data structures.
        redanddead 4y ago
        what's your favorite thing about interfaces and why?
  - davnicwil 4y ago
    I find it catches a lot of design mistakes for me which I would put in the non-trivial bugs category. Many bugs that result from design mistakes are less immediate, like hard to spot edge cases (a better design makes them impossible) or code that lends itself to becoming messier and more bug prone in the future as it's changed/extended (a better design makes this less likely).
    - jshen 4y ago
      I’ve had the opposite experience with complex type systems. They make it harder to evolve out of bad designs. This is particularly true when a lot of inheritance is used.
      - davnicwil 4y ago
        Interesting. What I've found is that when I come up with some pattern that is hard to type, or I have two parts of a system that need to work together but the interface can't be typed simply or doesn't quite 'fit', it is almost always the case that changing things around until the types do work straightforwardly uncovers a better design. This is definitely sometimes not easy, and of course it'll get more difficult generally the more code there is or the more complex (usually meaning bad!) the design is, but I'd almost put it the other way round to your perspective - the types are like the signposts in this design evolution and discovery process. They don't make it easier to do the work of refactoring a design, but they do make it much easier to understand when I'm going in a good/bad direction and also when I have succeeded.
        jshen 4y ago
        You are describing writing code alone. I’m thinking about other peoples code I’ve had to deal with where I didn’t create the types. Not saying I’m great at it, but that you can’t always control the quality of the code you have to work on.
      - zarzavat 4y ago
        That is true for nominal type systems such as Java’s. However TypeScript’s structural typing is much more flexible, because it is designed to describe the types of all the existing JavaScript code out there (via the DefinitelyTyped project). This gives the best of both worlds: the freedom to express the architecture you need, plus the freedom to actually refactor an existing code base into that new architecture without introducing many bugs. Dynamically typed languages give you the former but not the latter.
  - miiiiiike 4y ago
    Many bugs are trivial until they slip into production.
  - jjnoakes 4y ago
    You get 100% code coverage within 1 second of page load?
  - throwaway0asd 4y ago
    Exactly, you have to run the code before you realize it’s defective and even then only the defects that execute will get any attention. With TypeScript the defects yell at you before executing the code.
    - jshen 4y ago
      But at what cost? We shouldn’t assume it’s free
      - throwaway0asd 4y ago
        The cost is the compile time. My personal application is about 50k loc so the compile time is about 9 seconds with TSC or 1.5 seconds with SWC.
        jshen 4y ago
        There are other costs. One study I’ve seen found that writing libraries with typed generic code too longer to write, but we’re slightly faster to use. I’ve found that changing peoples badly typed code is worse than changing similar dynamic code. In short, there is very little empirical data on this, and it’s almost entirely anecdotal. My gut feeling is that if typing were a huge benefit it wouldn’t be so hard to prove.
        throwaway0asd 4y ago
        Avoid things like generics. Keep your types as primitive as possible. Strong typing will covert an excellent developer into an amazing developer but won’t do anything for extremely bad developers. Data types are not a solution to people problems.
        jshen 4y ago
        Agree, but the question for me is whether it is clear that it’s better at organizational scale over decades. I think it is, but not hugely so. Edit: I should add that I think there are a ton of things that are far more important for a high performing dev team than types.
  - hbrn 4y ago
    Runtime errors are the easiest to catch and fix. With TS you're paying the full price (in verbosity and complexity) but getting 10% of the value. There probably still are projects where it's a good deal, but my bet is they are the minority.
adamddev1 4y ago
I've written some projects w really complicated data and I personally think it would take 5x as long or push me to almost give up if I didn't have type checking.

Can be said about regular modern JS as well. Whether your project has types or not is not alone going to determine the success of the project.

by sgt 4y ago

Can be said about regular modern JS as well. Whether your project has types or not is not alone going to determine the success of the project.

zarzavat 4y ago

I personally can’t agree with that. TS catches me writing numerous bugs a day, the structural typing plus static analysis is a superb combination. If your code base is in JS without types, you probably have many bugs, you just don’t know about them. Especially around undefined/null handling. TypeScript also allows me to refactor fearlessly, which substantially improves the quality of my code as I can do mini-rewrites without worrying about breaking interfaces.

adamddev1 4y ago
Nothing as satisfying as quickly adjusting all the red squiggly lines after a big refactor and then seeing everything run perfectly again.
xodeus 4y ago
> TS catches me writing numerous bugs a day I see this sentiment a lot but I honestly can't think of any non-trivial bugs that TS has caught for me. 99% of the bugs it catches I would see 1 second later when my page hot reloads and crashes.
- vsnf 4y ago
  That’s the beauty though, isn’t it. Most bugs are trivial. I appreciate typescript getting the trivial bugs right more often than I’d trust myself to do so.
  - dleslie 4y ago
    Right? The argument that static/strict typing mostly catches trivial bugs isn't an argument against the value of that language, and yet people seem to think it is!
    - alrlroipsp 4y ago
      Let them fight windmills while we have a good time.
    - DogLover_ 4y ago
      I have to disagree. Adding the types will increase the number of the characters/lines of code which with a 80-char formatter limit can make functions look almost gibberish at a glance. Do that on a whole codebase and it becomes a mess to look at.
      - eyelidlessness 4y ago
        And I have to disagree in turn. Those additional characters and lines of code are documentation, and turn gibberish into not only human-readable clarity about the code you’re reading, but a machine-traversable dependency graph as well.
        hbrn 4y ago
        The problem is that they are forced documentation. You can't choose to skip it after you became familiar with it.
        eyelidlessness 4y ago
        That sounds like a VSCode extension I could write on a Saturday morning but whatever.
      - _0w8t 4y ago
        The verbosity of TypeScript types can be attributed to poor choice of syntax and names that became obvious retrospectively. Still even with TypeScript if types makes your functions ugly, then it shows the complexity of the code. Often it also suggests sensible refactoring that without types would not be apparent.
        DogLover_ 4y ago
- fifticon 4y ago
  well I can, I wrote a year-long js project that I abandoned as refactorings gradually turned into eternal bug-fests. I started from scratch in typescript, and the project is now 3x the dead project, with none of the bugs. and refactorings have become painless, with the compiler tools and editor telling me what I must fix up. There may be a special breed of programmers who need no such help, but I have yet to meet them in my 32+y long professional programming career :-)
  - mixmastamyk 4y ago
    You still have bugs, you just haven't found them yet. When strict typing is not available you adjust and use other tooling and tests. Of course with a big, venerable project the balance changes drastically. But an experienced single-person project should be doable with javascript for a long while and may even get to MVP faster by focusing on things that are essential.
    - CodeWriter23 4y ago
      I’ve been coding professionally for 39 years. ts seemed very strange to me at first. Only even started using it because I had to do some customization in NetSuite and some third party type and build support in ts made comprehensible the typically-stilted and insane NetSuite js required by SuiteScript. Now I’m addicted to it. Specifically the lightweight and easy to use _interface_ directive feeds my practice of self-documenting code with good doc and reusable data structures.
      - redanddead 4y ago
        what's your favorite thing about interfaces and why?
- davnicwil 4y ago
  I find it catches a lot of design mistakes for me which I would put in the non-trivial bugs category. Many bugs that result from design mistakes are less immediate, like hard to spot edge cases (a better design makes them impossible) or code that lends itself to becoming messier and more bug prone in the future as it's changed/extended (a better design makes this less likely).
  - jshen 4y ago
    I’ve had the opposite experience with complex type systems. They make it harder to evolve out of bad designs. This is particularly true when a lot of inheritance is used.
    - davnicwil 4y ago
      Interesting. What I've found is that when I come up with some pattern that is hard to type, or I have two parts of a system that need to work together but the interface can't be typed simply or doesn't quite 'fit', it is almost always the case that changing things around until the types do work straightforwardly uncovers a better design. This is definitely sometimes not easy, and of course it'll get more difficult generally the more code there is or the more complex (usually meaning bad!) the design is, but I'd almost put it the other way round to your perspective - the types are like the signposts in this design evolution and discovery process. They don't make it easier to do the work of refactoring a design, but they do make it much easier to understand when I'm going in a good/bad direction and also when I have succeeded.
      - jshen 4y ago
        You are describing writing code alone. I’m thinking about other peoples code I’ve had to deal with where I didn’t create the types. Not saying I’m great at it, but that you can’t always control the quality of the code you have to work on.
    - zarzavat 4y ago
      That is true for nominal type systems such as Java’s. However TypeScript’s structural typing is much more flexible, because it is designed to describe the types of all the existing JavaScript code out there (via the DefinitelyTyped project). This gives the best of both worlds: the freedom to express the architecture you need, plus the freedom to actually refactor an existing code base into that new architecture without introducing many bugs. Dynamically typed languages give you the former but not the latter.
- miiiiiike 4y ago
  Many bugs are trivial until they slip into production.
- jjnoakes 4y ago
  You get 100% code coverage within 1 second of page load?
- throwaway0asd 4y ago
  Exactly, you have to run the code before you realize it’s defective and even then only the defects that execute will get any attention. With TypeScript the defects yell at you before executing the code.
  - jshen 4y ago
    But at what cost? We shouldn’t assume it’s free
    - throwaway0asd 4y ago
      The cost is the compile time. My personal application is about 50k loc so the compile time is about 9 seconds with TSC or 1.5 seconds with SWC.
      - jshen 4y ago
        There are other costs. One study I’ve seen found that writing libraries with typed generic code too longer to write, but we’re slightly faster to use. I’ve found that changing peoples badly typed code is worse than changing similar dynamic code. In short, there is very little empirical data on this, and it’s almost entirely anecdotal. My gut feeling is that if typing were a huge benefit it wouldn’t be so hard to prove.
        throwaway0asd 4y ago
        Avoid things like generics. Keep your types as primitive as possible. Strong typing will covert an excellent developer into an amazing developer but won’t do anything for extremely bad developers. Data types are not a solution to people problems.
        jshen 4y ago
        Agree, but the question for me is whether it is clear that it’s better at organizational scale over decades. I think it is, but not hugely so. Edit: I should add that I think there are a ton of things that are far more important for a high performing dev team than types.
- hbrn 4y ago
  Runtime errors are the easiest to catch and fix. With TS you're paying the full price (in verbosity and complexity) but getting 10% of the value. There probably still are projects where it's a good deal, but my bet is they are the minority.

adamddev1 4y ago

I've written some projects w really complicated data and I personally think it would take 5x as long or push me to almost give up if I didn't have type checking.