3 ms·

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 significantl

by 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.
      - wtetzner 6y ago
        Sorry, I worded that poorly. What I should have said is that we don't have proof/disproof, because nobody has figured out how to do the experiment(s) needed to get there.

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.
    - wtetzner 6y ago
      Sorry, I worded that poorly. What I should have said is that we don't have proof/disproof, because nobody has figured out how to do the experiment(s) needed to get there.