6 ms·

> 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

• 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
          Typscript: "function area(left: number, top: number, right: number, bottom: number): number {" Javascript: "function area(left, top, right, bottom)" In an editor the typescript function would likely be split into five separate lines. "function area( left: number, top: number, right: number, bottom: number) : number {" None of the functions are complex but the the typescript function with the formatter creates a lot of noise.
          • dleslie 4y ago
            It's not noise, it's informative content. It also means it's not going to explode when fed the wrong types, because that's not possible.
            • BigJono 4y ago
              The only way it can not be noise is if you have no idea what your types are. That's a terrible way to code. If I'm working on a function foo(bar, baz), I know exactly what bar and baz are before looking at a single line of it, I've been tracing the code through to that function, how could I not know what the data types are at that point?
              • atom_arranger 4y ago
                The other people on/joining your team probably don’t know.
              • dleslie 4y ago
                It's normal not to be aware of the types when encountering code for the first time, or after a long absence. Your described experience is the rare exception when working with third party vendors, on long lived projects, or with teams that are not trivially small.
      • dleslie 4y ago
        Character input time is a vanishingly small concern for overall productivity. If it's a concern then you'll probably catch more bugs by slowing down to think.
        • DogLover_ 4y ago
          Typing it is not the problem. It is reading at a glance that becomes much harder since lines oftentimes get split into multilines. I get less of an overview.
          • dleslie 4y ago
            It's all still there, except with even more helpful information. If there are so many parameters that it falls out of mental context then there's too many parameters.
• 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.