3 ms·

Ok, so 50%, 95%--whatever your number is--of the code in Haskell we have established is susceptible to dramatically fewer bugs than any other language out there

Ok, so 50%, 95%--whatever your number is--of the code in Haskell we have established is susceptible to dramatically fewer bugs than any other language out there. How can you possibly claim it doesn't matter? Just because you can construct a situation where it seems to not matter doesn't mean that situation is representative. And oh by the way, we can easily prevent your situation in Haskell as well. safeRm :: SafeFilePath -> IO () Then we create the SafeFilePath data type (it can even be a newtype, which means it will have zero performance overhead) and we can write a smart constructor that makes it impossible to ever have dollar signs, stars, or anything else that might cause this kind of bug. mkSafeRm :: String -> Maybe SafeFilePath Then you hide that stuff away in a module and only expose a safe interface. Now, BOOM, safeRm cannot possibly ever have the bug you described. This is made possible by purity, strong static types, and the module system. Some mainstream languages allow you to partly achieve this, but it usually incurs lots of boilerplate and the lack of immutability means that there will be more holes in whatever solution you can come up with.

infraruby 12y ago
> 95% [...] of the code in Haskell we have established is susceptible to dramatically fewer bugs than any other language out there. No! Haskell has about the same proportion of LOC performing IO as any language. In Haskell, it may be easier to find where the IO code is, using the type system, but that doesn't make any of the code correct. > Then you hide that stuff away in a module and only expose a safe interface. You could do that in any language.
- tome 12y ago
  I think you are talking past each other. Indeed Haskell does not automatically make code higher quality than any other language. On the other hand, Haskell provides more infrastructure for making code reliable than most (or maybe all) mainstream languages.
  - infraruby 12y ago
    Did you read the thread? :-p > Haskell provides more infrastructure for making code reliable than most (or maybe all) mainstream languages. Is there any empirical evidence that Haskell programs really are more reliable (all else being equal)? Is all that infrastructure actually useful?
- mightybyte 12y ago
  Now you're not even listening to what I said. In my topmost post in this thread I showed how pure code in Haskell is susceptible to dramatically fewer potential bugs than equivalent code in any other mainstream language. I said: > There are no other possibilities, period. And you agreed: > That's true! Most of that bug reduction was made possible by Haskell's purity/immutability. Now you're completely ignoring that point that we already established. > In Haskell, it may be easier to find where the IO code is, using the type system, but that doesn't make any of the code correct. No, it doesn't deductively "make any of the code more correct". It makes the code inductively "more likely to be correct". You asked for empirical evidence for the inductive claim and I gave it to you. > You could do that in any language. No, you could not. Other languages have module systems with hiding, but they do not have purity, the ability to categorically eliminate things like null errors, etc. You're zooming in to one feature, but it's not just one feature that enables all this. It's the combination of several.
  - infraruby 12y ago
    > And you agreed: I did agree that you can prove some properties about your code. Specifically, you can prove which parts of the code do not perform IO, and in that limited sense "if it compiles, it works" for that example, but that does not hold in general. I did not agree that your code is more likely to be correct in general. The non-IO code may still be wrong (as you said then: it could return the first element of the list instead of the last one) and the IO code may also be wrong. And you have no evidence that any of that code is more likely to be correct. The Haskell compiler can enforce some organization on your code (IO code goes here, non-IO code goes there) but the bugs could still be anywhere. All you have done is to shift the deckchairs on the Titanic! > Most of that bug reduction was made possible by Haskell's purity/immutability. You have no evidence of any actual bug reduction. > You asked for empirical evidence for the inductive claim and I gave it to you. Working deductively from the definition of Haskell is not empirical evidence for the claim that Haskell programs are more likely to be correct.
    - mightybyte 12y ago
      > And you have no evidence that any of that code is more likely to be correct. > You have no evidence of any actual bug reduction. > Working deductively from the definition of Haskell is not empirical evidence for the claim that Haskell programs are more likely to be correct. My deductive reasoning is not the evidence I'm citing here. We counted the total number of ways that a function could go wrong and saw that in pure Haskell code, the number is drastically reduced. We know that the bug types we eliminated actually occur in practice, so under the reasonable assumption that the distribution of bug types is relatively constant, those numbers do provide empirical evidence (observational, not experimental) that Haskell programs are more likely to be correct. Yes, pure code can still be wrong, but it can be wrong in a lot less ways than the impure code that you're stuck with in other languages. That code is still doing useful work that is also bug-prone in other languages. Therefore we can be reasonably confident that it will reduce bugs. If you absolutely insist on experimental evidence, we have that too: https://www.youtube.com/watch?v=BveDrw9CwEg#t=1207 https://www.youtube.com/watch?v=BveDrw9CwEg#t=1207

infraruby 12y ago

> 95% [...] of the code in Haskell we have established is susceptible to dramatically fewer bugs than any other language out there. No! Haskell has about the same proportion of LOC performing IO as any language. In Haskell, it may be easier to find where the IO code is, using the type system, but that doesn't make any of the code correct. > Then you hide that stuff away in a module and only expose a safe interface. You could do that in any language.

tome 12y ago
I think you are talking past each other. Indeed Haskell does not automatically make code higher quality than any other language. On the other hand, Haskell provides more infrastructure for making code reliable than most (or maybe all) mainstream languages.
- infraruby 12y ago
  Did you read the thread? :-p > Haskell provides more infrastructure for making code reliable than most (or maybe all) mainstream languages. Is there any empirical evidence that Haskell programs really are more reliable (all else being equal)? Is all that infrastructure actually useful?
mightybyte 12y ago
Now you're not even listening to what I said. In my topmost post in this thread I showed how pure code in Haskell is susceptible to dramatically fewer potential bugs than equivalent code in any other mainstream language. I said: > There are no other possibilities, period. And you agreed: > That's true! Most of that bug reduction was made possible by Haskell's purity/immutability. Now you're completely ignoring that point that we already established. > In Haskell, it may be easier to find where the IO code is, using the type system, but that doesn't make any of the code correct. No, it doesn't deductively "make any of the code more correct". It makes the code inductively "more likely to be correct". You asked for empirical evidence for the inductive claim and I gave it to you. > You could do that in any language. No, you could not. Other languages have module systems with hiding, but they do not have purity, the ability to categorically eliminate things like null errors, etc. You're zooming in to one feature, but it's not just one feature that enables all this. It's the combination of several.
- infraruby 12y ago
  > And you agreed: I did agree that you can prove some properties about your code. Specifically, you can prove which parts of the code do not perform IO, and in that limited sense "if it compiles, it works" for that example, but that does not hold in general. I did not agree that your code is more likely to be correct in general. The non-IO code may still be wrong (as you said then: it could return the first element of the list instead of the last one) and the IO code may also be wrong. And you have no evidence that any of that code is more likely to be correct. The Haskell compiler can enforce some organization on your code (IO code goes here, non-IO code goes there) but the bugs could still be anywhere. All you have done is to shift the deckchairs on the Titanic! > Most of that bug reduction was made possible by Haskell's purity/immutability. You have no evidence of any actual bug reduction. > You asked for empirical evidence for the inductive claim and I gave it to you. Working deductively from the definition of Haskell is not empirical evidence for the claim that Haskell programs are more likely to be correct.
  - mightybyte 12y ago
    > And you have no evidence that any of that code is more likely to be correct. > You have no evidence of any actual bug reduction. > Working deductively from the definition of Haskell is not empirical evidence for the claim that Haskell programs are more likely to be correct. My deductive reasoning is not the evidence I'm citing here. We counted the total number of ways that a function could go wrong and saw that in pure Haskell code, the number is drastically reduced. We know that the bug types we eliminated actually occur in practice, so under the reasonable assumption that the distribution of bug types is relatively constant, those numbers do provide empirical evidence (observational, not experimental) that Haskell programs are more likely to be correct. Yes, pure code can still be wrong, but it can be wrong in a lot less ways than the impure code that you're stuck with in other languages. That code is still doing useful work that is also bug-prone in other languages. Therefore we can be reasonably confident that it will reduce bugs. If you absolutely insist on experimental evidence, we have that too: https://www.youtube.com/watch?v=BveDrw9CwEg#t=1207 https://www.youtube.com/watch?v=BveDrw9CwEg#t=1207