4 ms·

Neither will Haskell, Rust, etc. The extra classes of mistakes they can prevent at compile time just aren’t a meaningful volume of mistakes to make a practical

by mlthoughts2018 6y ago

Neither will Haskell, Rust, etc. The extra classes of mistakes they can prevent at compile time just aren’t a meaningful volume of mistakes to make a practical difference in the lives of any developers apart from a few niche system engineering use cases. If you think languages should facilitate type system design patterns that render large classes of application level mistakes impossible, you are just an architectural astronaut falling prey to premature abstraction and unaware that these languages aren’t making your application code safer or more reliable, only more brittle to the inevitable needs to break its core abstractions to solve expanding use cases.

ameliaquining 6y ago
This is a very strong claim. Do you have evidence for it? (Yes, I'm aware that there've been a bunch of studies that didn't find decreased "bug density" in open source repos using statically typed languages, but there've also been studies that found the opposite, and in any event the methodology behind all of these is dubious. Example saga: https://hillelwayne.com/post/this-is-how-science-happens/ https://hillelwayne.com/post/this-is-how-science-happens/)
- mlthoughts2018 6y ago
  I disagree it’s a strong claim. I think the claim that strict functional programming or type system enforcement of safety has no data supporting it significantly improves anything (defect rate, speed of development, security, etc.). The strong claims come from evangelists of those extreme programming paradigms. You should be asking them for proof that consists of more than anecdata. It’s backwards to say that essentially what is a historically validated null hypothesis with 50 years of development history on its side is “a strong claim” that requires special evidence, while giving a free pass to all the people using little more than blog posts and slick syntax to claim these extreme design patterns are demonstrably better. If they are so much better, where are all the companies getting free lunches just by switching to these tools? How is it that the entire industry is so irrational that so few companies are willing to switch? Superior ways of working catch on very fast, just consider the radical adoption of GitHub and no-sql data systems. Why is strict functional programming not seeing that? What mental gymnastics does it require to take as a premise that strict functional programming is “better” yet adoption rates are super low and successes are not proved with data, only anecdotes?
  - wtetzner 6y ago
    > It’s backwards to say that essentially what is a historically validated null hypothesis with 50 years of development history on its side is “a strong claim” that requires special evidence I really don't see your point here. Are you suggesting that because people have been able to write software in C for 50 years that type systems aren't useful? Because it's not like those programs are bug free. It also doesn't take into account how much effort is need to build and maintain that software. Also not really sure what you're getting at about strict functional programming. This post was just about type checking. > Neither will Haskell, Rust, etc. Rust is really in no way a functional language.
    - mlthoughts2018 6y ago
      I don’t see your point. What does the bugfreeness of historically used approaches have to do with it. The new kids on the block have to prove they are better in some tangible way. The onus is not on established programming languages to prove anything. As far as evidence is concerned, you’re not going to solve problems faster, safer, cheaper, more reliably or more extensibly with Rust or Haskell than you are with C or Python, apart from some very niche exceptions. That just an empirical observation, not an opinion.
      - wtetzner 6y ago
        > The onus is not on established programming languages to prove anything. Why is there no onus on "established" programming languages (whatever that means)? It's not like production software hasn't been shipped in Rust, Haskell, OCaml, etc. Just because C is older it gets a free pass? > As far as evidence is concerned I would argue there's plenty of evidence that languages with better type system are valuable. What we don't have is proof, but that's because nobody has figured out how to do the experiment(s).
        oalae5niMiel7qu 6y ago
        No, it's because either nobody has figured out how to do the experiments, OR because their hypothesis is invalid and they merely haven't disproven it.
ansible 6y ago
This blog post makes the opposite assertion: http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c-to-rust.html http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c... Most security bugs in qemu have been C programming bugs, like a NULL pointer dereference.

ameliaquining 6y ago

This is a very strong claim. Do you have evidence for it? (Yes, I'm aware that there've been a bunch of studies that didn't find decreased "bug density" in open source repos using statically typed languages, but there've also been studies that found the opposite, and in any event the methodology behind all of these is dubious. Example saga: https://hillelwayne.com/post/this-is-how-science-happens/ https://hillelwayne.com/post/this-is-how-science-happens/)

mlthoughts2018 6y ago
I disagree it’s a strong claim. I think the claim that strict functional programming or type system enforcement of safety has no data supporting it significantly improves anything (defect rate, speed of development, security, etc.). The strong claims come from evangelists of those extreme programming paradigms. You should be asking them for proof that consists of more than anecdata. It’s backwards to say that essentially what is a historically validated null hypothesis with 50 years of development history on its side is “a strong claim” that requires special evidence, while giving a free pass to all the people using little more than blog posts and slick syntax to claim these extreme design patterns are demonstrably better. If they are so much better, where are all the companies getting free lunches just by switching to these tools? How is it that the entire industry is so irrational that so few companies are willing to switch? Superior ways of working catch on very fast, just consider the radical adoption of GitHub and no-sql data systems. Why is strict functional programming not seeing that? What mental gymnastics does it require to take as a premise that strict functional programming is “better” yet adoption rates are super low and successes are not proved with data, only anecdotes?
- wtetzner 6y ago
  > It’s backwards to say that essentially what is a historically validated null hypothesis with 50 years of development history on its side is “a strong claim” that requires special evidence I really don't see your point here. Are you suggesting that because people have been able to write software in C for 50 years that type systems aren't useful? Because it's not like those programs are bug free. It also doesn't take into account how much effort is need to build and maintain that software. Also not really sure what you're getting at about strict functional programming. This post was just about type checking. > Neither will Haskell, Rust, etc. Rust is really in no way a functional language.
  - mlthoughts2018 6y ago
    I don’t see your point. What does the bugfreeness of historically used approaches have to do with it. The new kids on the block have to prove they are better in some tangible way. The onus is not on established programming languages to prove anything. As far as evidence is concerned, you’re not going to solve problems faster, safer, cheaper, more reliably or more extensibly with Rust or Haskell than you are with C or Python, apart from some very niche exceptions. That just an empirical observation, not an opinion.
    - wtetzner 6y ago
      > The onus is not on established programming languages to prove anything. Why is there no onus on "established" programming languages (whatever that means)? It's not like production software hasn't been shipped in Rust, Haskell, OCaml, etc. Just because C is older it gets a free pass? > As far as evidence is concerned I would argue there's plenty of evidence that languages with better type system are valuable. What we don't have is proof, but that's because nobody has figured out how to do the experiment(s).
      - oalae5niMiel7qu 6y ago
        No, it's because either nobody has figured out how to do the experiments, OR because their hypothesis is invalid and they merely haven't disproven it.

ansible 6y ago

This blog post makes the opposite assertion: http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c-to-rust.html http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c... Most security bugs in qemu have been C programming bugs, like a NULL pointer dereference.