4 ms·

> 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

by 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.
        continuitylimit 3y ago
        Rigor is not the only variable, agreed. The issue (again) is that the other variables are many and they are non-linear in the main. (For example, the variable of ‘competence of development organization’ is not smoothly distributed. Our field is not a “smooth” domain it is ‘chunky’.) So where does that leave us? Opinions are one option - comparative views to other ‘industrial’ age type of activities may be informative. I propose to you that “we moderns” live in a typed world. It is not strongly typed but it is typed. One could argue that that is a side-effect of physical world artifacts produced at scale. I would be interested in hearing the argument as to why that near universal phenomena* does not apply to software, in your opinion. (* Industrial production at scale and emergence of standards)
  - UncleMeat 3y ago
    Yeah this is the unfortunate reality of software engineering methodology research. As a field we simply don't have strong and reliable research demonstrating what makes teams more productive or software more reliable. And we don't even seem to have new methodological ideas on the horizon to come save us.
  - maattdd 3y ago
    There is this comparison of student projects in different languages https://thume.ca/2019/04/29/comparing-compilers-in-rust-haskell-c-and-python/ https://thume.ca/2019/04/29/comparing-compilers-in-rust-hask...
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.

by marwis 3y ago

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.
      - continuitylimit 3y ago
        Rigor is not the only variable, agreed. The issue (again) is that the other variables are many and they are non-linear in the main. (For example, the variable of ‘competence of development organization’ is not smoothly distributed. Our field is not a “smooth” domain it is ‘chunky’.) So where does that leave us? Opinions are one option - comparative views to other ‘industrial’ age type of activities may be informative. I propose to you that “we moderns” live in a typed world. It is not strongly typed but it is typed. One could argue that that is a side-effect of physical world artifacts produced at scale. I would be interested in hearing the argument as to why that near universal phenomena* does not apply to software, in your opinion. (* Industrial production at scale and emergence of standards)
- UncleMeat 3y ago
  Yeah this is the unfortunate reality of software engineering methodology research. As a field we simply don't have strong and reliable research demonstrating what makes teams more productive or software more reliable. And we don't even seem to have new methodological ideas on the horizon to come save us.
- maattdd 3y ago
  There is this comparison of student projects in different languages https://thume.ca/2019/04/29/comparing-compilers-in-rust-haskell-c-and-python/ https://thume.ca/2019/04/29/comparing-compilers-in-rust-hask...

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.