6 ms·

>I think most people would agree that types prevent a lot of bugs Again, that's not what research shows. Type checking bugs are most definitely not the most co

>I think most people would agree that types prevent a lot of bugs Again, that's not what research shows. Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language. I'm all for types, but after using TypeScript and seeing everyone (including the article) touting it as the solution, it simply isn't all that better than vanilla JS. I did spend countless hours having to wrangle typescript when integrating with third party libraries, searching for types that were not always there, manually extending/creating library types and so on. So no, it's not as clear cut as some say it is. If we want to argue for types, then we should use strongly typed languages that prevent these bugs (if you can manage to create the right types, of course). Examples in TypeScript are simply not going to cut it because that's a horrible example of a typed language. I mean, it's not even a language. Edit: above all, hard research. If there's research for this, why isn't that in the article?

marwis 3y ago
> Again, that's not what research shows. Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language. Can you point to that research?
- Draiken 3y ago
  This was the last one I read: http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ If there's more, I hope people reply here with it!
  - dang 3y ago
    Discussed a bit in past threads: The evidence behind strong claims about static vs. dynamic languages - https://news.ycombinator.com/item?id=16287083 https://news.ycombinator.com/item?id=16287083 - Feb 2018 (1 comment) The empirical evidence that types affect productivity and correctness - https://news.ycombinator.com/item?id=8594769 https://news.ycombinator.com/item?id=8594769 - Nov 2014 (25 comments)
  - gpderetta 3y ago
    As per your link is, it is not so much that "The research out there found no meaningful difference between both styles", but more than the research out there is utter garbage. Which is what I would expect: a proper research on the topic would be terribly expensive, requiring multiple teams reimplementing complex projects in different languages and separate distinct expert panels evaluating development and results.
    - Draiken 3y ago
      Yeah, which is a shame. Because I truly wanted to be confident that the costs of these don't outweigh the benefits. Regardless if it's no meaningful difference or no good research, the point remains: we simply don't know, so these discussions are about opinions for either side, not facts.
      - continuitylimit 3y ago
        No, the point does not remain that “research” “shows” anything. Seems there is agreement that ‘meaningful experiments have never been done because it is too complex and expensive’ so there is no significant research data. But the basic argument is that a programming approach — having a compiler and a type system is not a “style” btw — that employs development time tools to reduce the burden of runtime operational tools, afford greater application of a wider set of optimization techniques at runtime, and also add to the information bandwidth of source code via type annotations is reasonably expected to be more rigorous than the other approach.
        Draiken 3y ago
        Fair point. If there was good research showing no difference, it would be equally pointless to argue either side is right, but it wouldn't be mere opinions, like they are today. As for the move between runtime to development time tools, it still misses the cost of it. We could move all our code to Haskell and have absolute guarantees for a lot of the common found bugs, but we don't because it's costly. And I don't mean rewrite cost, I mean the cost of its own complexities. Nobody argues that typed languages aren't more rigorous, but that's not the only variable we care about.
- solumunus 3y ago
  > typing doesn't really help with runtime bugs unless it's a strongly typed language I’m skeptical of this research. Typescript prevents runtime bugs for me day in day out. It also allows me to produce much more elegant and flexible solutions which would be infeasible in plain JavaScript. When people say there is no significant benefit compared to JavaScript it almost feels like I must be on a different planet or something. I would love to see what kind of code these people are working with, or how they’re attempting to leverage the type system.
  - kazinator 3y ago
    Would you still favor Typescript if it was an actual static language: such that a type problem not caught by Typescript potentially corrupted memory and crashed the browser or Node.js instance?
    - nyssos 3y ago
      > such that a type problem not caught by Typescript potentially corrupted memory What does this have to do with static types? High-level languages, typed or untyped, are generally memory-safe. They'd need a very good excuse not to be. If Haskell isn't a "real" statically typed language, nothing is.
      - kazinator 3y ago
        A True Scotsman's statically typed language is not safe if the type system is defeated; then it's up to the programmer to ensure safety. TypeScript is not this; it's a type checking layer over a dynamic language.
chrisco255 3y ago
> Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language. TypeScript actually performed quite well in the last academic study I read on this debate (like 6 years ago). The real problem with web APIs is that there is always some lossy conversion between type systems as we cross boundaries. So we can't really make some sort of closed system assumption. A typical web app may interact with dozens of API services, some run by third parties. And maybe you can trust their API docs, but maybe not really, and they're subject to updates anyways, so you always have to be on your toes. Even internally, you can't really control all the type info from end to end. Even the most monolithic systems will have some sort of abstraction leak when going from JSON -> Object -> Relational storage. Even largely monolithic systems will typically break off some functionality (like email sending, websockets handling, etc) as a separate service. The boundary creates a co-evolving connection between separate services run by separate teams, with separate upgrade cycles, even without full microservices buy in. And that creates potential runtime type errors when mapping between these layers. Even if you've somehow plugged all those leaky abstractions and your tight type system has handled all the edge cases and is provably correct: the user will teach you otherwise on the UI layer. User input can vary wildly, and everything from device capabilities to personal disabilities to network throttling to authentication to using weird ISO characters to file sizes to strange input devices and legacy systems with their own quirks, will completely throw you off at some point. So no matter how type safe your language is, you'll always have to deal with the untyped and unpredictable user layer. And the reason why JS has been so successful there is because of how flexible it is. It's not as painful to make quick tweaks with JS as it is with a type system like Rust's, for example. JS, for all its quirks, made a good amount of trade-offs for its target platform. Type errors are almost always the easiest types of errors to fix. What really will get you is debugging interdependent systems and services, and that pesky user layer. But people will spend extraordinary amounts of time maintaining complex type systems just so their OCD can be satisfied about believing, that at least for a moment, if their program compiles...that all is right with the world for that brief moment just before you deploy to production. Oh were that the case. I do think types are essential for mission and life critical systems, but testing is even more essential for those cases, so everything should already be thoroughly covered. For consumer apps, however, is it worth the cost in velocity?
the_af 3y ago
> Type checking bugs are most definitely not the most common ones This is not a facetious question, so bear with me: what is a "type checking bug"? Do you mean "a bug in language L that would have been caught by the typechecker T, if only L had it"? That's the only meaning I can think of that makes sense [1] (ok, thought of another one [2]). But what does it mean that "most bugs" aren't of that kind? Is it that "most bugs are of a kind that cannot be caught by any conceivable typechecker"? -- [1] We can safely disregard the other possible interpretation of "a type checking bug is a bug in the typechecker itself" ;) [2] Maybe "this expected a list but I passed it an integer instead"? I do occasionally trip over those with Python, but I think most typecheckers are more advanced than that, and can check for more interesting classes of bugs.
- Draiken 3y ago
  Forgive me if I didn't use the right terminology too. What I mean by type checking bugs are the kinds of bugs shown in the article: I have an argument that should be a number but someone accidentally uses it with a string instead. That's the most basic bug that typed languages catch. But for me, those are extremely simplistic. I don't need a type checker to know that. If you follow the code path you already know the types you're dealing with. What strongly typed languages can provide are types with constraints. E.g. an age is not only a number, but a valid number greater than zero (maybe with an upper bound?) that is attached to a person. That kind of strong guarantee will definitely catch runtime bugs if you pass in some other numeric value that is not a representation of an age. Languages like TypeScript can't do that. Take the example below. It compiles as if there's nothing wrong: type Age = number type Person = { age: Age } const person = { age: 10 } as Person const someRandomNumber = 10 function printAge(age: Age) { return console.log(age) } printAge(person.age) printAge(someRandomNumber) This is the kind of bug that a good type system would be extremely helpful with. In my entire career it's definitely a lot more common than passing a string by mistake. This can be extended for having a type that differentiates an `Email` from a `ValidEmail`, an `ActiveUser` from an `User` and so on. Those are, in my view, where a type system can truly help us catch bugs. But even if you have a type system that supports that, nothing stops someone from simply using `number` instead of `Age`. In any case, that's why I don't think it's as clear cut as people put it. Yes, in very rare occasions TS will tell me I accidentally allowed something that can be undefined pass (excluding the many times it gets it wrong). However that doesn't come for free and that is what makes absolutist claims for either side unhelpful.
littlestymaar 3y ago
> Again, that's not what research shows. Type checking bugs are most definitely not the most common ones It's likely not the most common bug family to reach production or to be published on github so it will be visible to researchers doing their studies (survivorship bias…), but they are definitely the most common bug I'm facing when using an untyped language, and the majority of developers shares this sentiment. Of course you'd argue that personal feeling isn't science, but studies falling to survivorship bias aren't good science either…
- Draiken 3y ago
  Not all of that research was done with public code. But they had other flaws. I should have prefaced that with "IMO". That particular sentence comes from my experience/career, so YMMV. When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. But then again, I worked with dynamic languages for a long time and this could be a skill I picked up because of it.
  - littlestymaar 3y ago
    > When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. Even when dealing with third-party code, or joining an existing project?
    - Draiken 3y ago
      That's the first thing you do: read/learn the data structures you're working with. As Linus said once: > Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Of course I still have to read and learn that. But that's the same with or without a typed language. Whether your data is an unstructured hash or a carefully typed structure, you need to know it. Way too many people rely on ctrl+space based programming, figuring out everything as they go. One aspect that dynamic typed languages forces into us (at least it does to me), is to learn the data structure and relationships more thoroughly.
antifa 3y ago
> then we should use strongly typed languages that prevent these bugs So Typescript then? The most common recurring bugs on my team is front-end devs not knowing the shape or property names of types written by other devs (backend, other font-end, themselves a month ago). If we moved to Typescript they would get those little spellcheck-like underlines pointing out these errors before they attempt to commit, rather than customer's pointing it out. Sounds like an argument against untrusted input, I just want Typescript so at least my own team becomes trusted input.

marwis 3y ago

> Again, that's not what research shows. Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language. Can you point to that research?

Draiken 3y ago
This was the last one I read: http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ If there's more, I hope people reply here with it!
- dang 3y ago
  Discussed a bit in past threads: The evidence behind strong claims about static vs. dynamic languages - https://news.ycombinator.com/item?id=16287083 https://news.ycombinator.com/item?id=16287083 - Feb 2018 (1 comment) The empirical evidence that types affect productivity and correctness - https://news.ycombinator.com/item?id=8594769 https://news.ycombinator.com/item?id=8594769 - Nov 2014 (25 comments)
- gpderetta 3y ago
  As per your link is, it is not so much that "The research out there found no meaningful difference between both styles", but more than the research out there is utter garbage. Which is what I would expect: a proper research on the topic would be terribly expensive, requiring multiple teams reimplementing complex projects in different languages and separate distinct expert panels evaluating development and results.
  - Draiken 3y ago
    Yeah, which is a shame. Because I truly wanted to be confident that the costs of these don't outweigh the benefits. Regardless if it's no meaningful difference or no good research, the point remains: we simply don't know, so these discussions are about opinions for either side, not facts.
    - continuitylimit 3y ago
      No, the point does not remain that “research” “shows” anything. Seems there is agreement that ‘meaningful experiments have never been done because it is too complex and expensive’ so there is no significant research data. But the basic argument is that a programming approach — having a compiler and a type system is not a “style” btw — that employs development time tools to reduce the burden of runtime operational tools, afford greater application of a wider set of optimization techniques at runtime, and also add to the information bandwidth of source code via type annotations is reasonably expected to be more rigorous than the other approach.
      - Draiken 3y ago
        Fair point. If there was good research showing no difference, it would be equally pointless to argue either side is right, but it wouldn't be mere opinions, like they are today. As for the move between runtime to development time tools, it still misses the cost of it. We could move all our code to Haskell and have absolute guarantees for a lot of the common found bugs, but we don't because it's costly. And I don't mean rewrite cost, I mean the cost of its own complexities. Nobody argues that typed languages aren't more rigorous, but that's not the only variable we care about.
solumunus 3y ago
> typing doesn't really help with runtime bugs unless it's a strongly typed language I’m skeptical of this research. Typescript prevents runtime bugs for me day in day out. It also allows me to produce much more elegant and flexible solutions which would be infeasible in plain JavaScript. When people say there is no significant benefit compared to JavaScript it almost feels like I must be on a different planet or something. I would love to see what kind of code these people are working with, or how they’re attempting to leverage the type system.
- kazinator 3y ago
  Would you still favor Typescript if it was an actual static language: such that a type problem not caught by Typescript potentially corrupted memory and crashed the browser or Node.js instance?
  - nyssos 3y ago
    > such that a type problem not caught by Typescript potentially corrupted memory What does this have to do with static types? High-level languages, typed or untyped, are generally memory-safe. They'd need a very good excuse not to be. If Haskell isn't a "real" statically typed language, nothing is.
    - kazinator 3y ago
      A True Scotsman's statically typed language is not safe if the type system is defeated; then it's up to the programmer to ensure safety. TypeScript is not this; it's a type checking layer over a dynamic language.

chrisco255 3y ago

> Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language. TypeScript actually performed quite well in the last academic study I read on this debate (like 6 years ago). The real problem with web APIs is that there is always some lossy conversion between type systems as we cross boundaries. So we can't really make some sort of closed system assumption. A typical web app may interact with dozens of API services, some run by third parties. And maybe you can trust their API docs, but maybe not really, and they're subject to updates anyways, so you always have to be on your toes. Even internally, you can't really control all the type info from end to end. Even the most monolithic systems will have some sort of abstraction leak when going from JSON -> Object -> Relational storage. Even largely monolithic systems will typically break off some functionality (like email sending, websockets handling, etc) as a separate service. The boundary creates a co-evolving connection between separate services run by separate teams, with separate upgrade cycles, even without full microservices buy in. And that creates potential runtime type errors when mapping between these layers. Even if you've somehow plugged all those leaky abstractions and your tight type system has handled all the edge cases and is provably correct: the user will teach you otherwise on the UI layer. User input can vary wildly, and everything from device capabilities to personal disabilities to network throttling to authentication to using weird ISO characters to file sizes to strange input devices and legacy systems with their own quirks, will completely throw you off at some point. So no matter how type safe your language is, you'll always have to deal with the untyped and unpredictable user layer. And the reason why JS has been so successful there is because of how flexible it is. It's not as painful to make quick tweaks with JS as it is with a type system like Rust's, for example. JS, for all its quirks, made a good amount of trade-offs for its target platform. Type errors are almost always the easiest types of errors to fix. What really will get you is debugging interdependent systems and services, and that pesky user layer. But people will spend extraordinary amounts of time maintaining complex type systems just so their OCD can be satisfied about believing, that at least for a moment, if their program compiles...that all is right with the world for that brief moment just before you deploy to production. Oh were that the case. I do think types are essential for mission and life critical systems, but testing is even more essential for those cases, so everything should already be thoroughly covered. For consumer apps, however, is it worth the cost in velocity?

the_af 3y ago

> Type checking bugs are most definitely not the most common ones This is not a facetious question, so bear with me: what is a "type checking bug"? Do you mean "a bug in language L that would have been caught by the typechecker T, if only L had it"? That's the only meaning I can think of that makes sense [1] (ok, thought of another one [2]). But what does it mean that "most bugs" aren't of that kind? Is it that "most bugs are of a kind that cannot be caught by any conceivable typechecker"? -- [1] We can safely disregard the other possible interpretation of "a type checking bug is a bug in the typechecker itself" ;) [2] Maybe "this expected a list but I passed it an integer instead"? I do occasionally trip over those with Python, but I think most typecheckers are more advanced than that, and can check for more interesting classes of bugs.

Draiken 3y ago
Forgive me if I didn't use the right terminology too. What I mean by type checking bugs are the kinds of bugs shown in the article: I have an argument that should be a number but someone accidentally uses it with a string instead. That's the most basic bug that typed languages catch. But for me, those are extremely simplistic. I don't need a type checker to know that. If you follow the code path you already know the types you're dealing with. What strongly typed languages can provide are types with constraints. E.g. an age is not only a number, but a valid number greater than zero (maybe with an upper bound?) that is attached to a person. That kind of strong guarantee will definitely catch runtime bugs if you pass in some other numeric value that is not a representation of an age. Languages like TypeScript can't do that. Take the example below. It compiles as if there's nothing wrong: type Age = number type Person = { age: Age } const person = { age: 10 } as Person const someRandomNumber = 10 function printAge(age: Age) { return console.log(age) } printAge(person.age) printAge(someRandomNumber) This is the kind of bug that a good type system would be extremely helpful with. In my entire career it's definitely a lot more common than passing a string by mistake. This can be extended for having a type that differentiates an `Email` from a `ValidEmail`, an `ActiveUser` from an `User` and so on. Those are, in my view, where a type system can truly help us catch bugs. But even if you have a type system that supports that, nothing stops someone from simply using `number` instead of `Age`. In any case, that's why I don't think it's as clear cut as people put it. Yes, in very rare occasions TS will tell me I accidentally allowed something that can be undefined pass (excluding the many times it gets it wrong). However that doesn't come for free and that is what makes absolutist claims for either side unhelpful.

littlestymaar 3y ago

> Again, that's not what research shows. Type checking bugs are most definitely not the most common ones It's likely not the most common bug family to reach production or to be published on github so it will be visible to researchers doing their studies (survivorship bias…), but they are definitely the most common bug I'm facing when using an untyped language, and the majority of developers shares this sentiment. Of course you'd argue that personal feeling isn't science, but studies falling to survivorship bias aren't good science either…

Draiken 3y ago
Not all of that research was done with public code. But they had other flaws. I should have prefaced that with "IMO". That particular sentence comes from my experience/career, so YMMV. When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. But then again, I worked with dynamic languages for a long time and this could be a skill I picked up because of it.
- littlestymaar 3y ago
  > When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. Even when dealing with third-party code, or joining an existing project?
  - Draiken 3y ago
    That's the first thing you do: read/learn the data structures you're working with. As Linus said once: > Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Of course I still have to read and learn that. But that's the same with or without a typed language. Whether your data is an unstructured hash or a carefully typed structure, you need to know it. Way too many people rely on ctrl+space based programming, figuring out everything as they go. One aspect that dynamic typed languages forces into us (at least it does to me), is to learn the data structure and relationships more thoroughly.

antifa 3y ago

> then we should use strongly typed languages that prevent these bugs So Typescript then? The most common recurring bugs on my team is front-end devs not knowing the shape or property names of types written by other devs (backend, other font-end, themselves a month ago). If we moved to Typescript they would get those little spellcheck-like underlines pointing out these errors before they attempt to commit, rather than customer's pointing it out. Sounds like an argument against untrusted input, I just want Typescript so at least my own team becomes trusted input.