6 ms·

> Do you see how that's totally unrelated to accidentally accessing an uninitialized variable? I was responding to your comments about Maybe, but, yes, that is

> Do you see how that's totally unrelated to accidentally accessing an uninitialized variable? I was responding to your comments about Maybe, but, yes, that is a separate issue. > While testing may eliminate some of these errors, it's even better if they cannot happen at all. That way you can focus your time on testing actual errors. A language which automatically disallows some classes of errors is safer than one where you have to remember to check for them. Perhaps. But perhaps it makes no actual difference in practice. And perhaps the cost of using Haskell, of satisfying the compiler, of fixing type errors that would not be (runtime) errors in a dynamically-typed language, perhaps that cost outweighs any benefit that type-checking may provide. I don't know. And neither do you. This entire thread I have asked for empirical evidence, but you have offered only deductive arguments, and that's fine, do as you like, but it's not persuasive. > Yes, fewer failure modes -> increased probability of correctness. That's an interesting hypothesis. I wonder what would be found in a comparative study of statically-typed Haskell code developed with the help of the compiler vs dynamically-typed Haskell code (more failure modes!) developed with the help of an interpreter (if this is possible). Using the same core language would eliminate many confounding variables. BTW, have you not heard "no true scotsman" before?

the_af 12y ago
> perhaps the cost of using Haskell, of satisfying the compiler, of fixing type errors that would not be (runtime) errors in a dynamically-typed language, perhaps that cost outweighs any benefit that type-checking may provide. That's completely irrelevant to the current discussion. We are not discussing convenience; we're discussing safety. Are you trying to de-rail the debate? :) By the way, because you're intent on "teaching" me what deduction and induction mean: not that it has anything to do with the argument at hand, but deductive reasoning (when you can apply it) trumps inductive. > > Yes, fewer failure modes -> increased probability of correctness. > That's an interesting hypothesis. That's... uh... that's not an hypothesis. Something that can fail in fewer ways is safer than something that can fail in more varied ways, all else being equal. There is no need for inductive reasoning here. > BTW, have you not heard "no true scotsman" before? I have, and I have also noticed you were trying to sarcastically invoke this fallacy all along. Unfortunately, it seems you've misunderstood it: No True Scotman applies when you make an assertion, then you're presented with a contradiction, and in order to counter it you adopt an ad hoc assertion which serves as an exception. The fallacy doesn't apply when the assertion is not ad hoc, but in fact that which defines the original assertion. Haskell programmers program using Maybe, that's not a "No True Scotman" fallacy. For example, if I said "Haskell programmers do X", and you say "that's not true for Haskell programmers using Ruby!" and I counter "I was talking about Haskell programmers using Haskell", that's not a case of No True Scotman. It's the same for Haskell programmers using the Maybe monad. Let me explain the kind of flawed reasoning you've been using so far. Say you read something about handguns with safeties being safer than handguns without safeties. You start "blah blah inductive reasoning no true scotman yadda yadda". When someone counters, "well, are you saying handguns with safeties designed to make them safer are not actually safer than handguns without safeties?" your reply seems to be "well, if you give the handgun with safety to a kid, load the gun, switch the safety off, and tell the kid to pull the trigger, then it's not safer!". Do you see the ridiculousness of your position? Any Turing complete language can be used improperly and cause harm. But some languages are safer than others by design. Not better, merely safer. For example, Haskell is safer than Ruby :)
- infraruby 12y ago
  > We are not discussing convenience; we're discussing safety. We were discussing whether Haskell programs are more likely to be correct (than bash programs), all else (including convenience) being equal. Who is more likely to write correct programs, for the same effort: a Haskell programmer or a bash programmer? Did you think we should allow the Haskell programmer more time, to satisfy an inconvenient type-checker? > you make an assertion, then you're presented with a contradiction, and in order to counter it you adopt an ad hoc assertion which serves as an exception. That is exactly what you did! You said "Haskell uses Maybe", I said "A Haskell programmer could [do something else]" and then anticipated a no true Haskell programmer fallacy, but you went right ahead anyway: the programmer who chooses to use fromMaybe has to decide what the actual default is, and since he has to consciously pick one, he will choose a useful one. Also, because he is using Haskell, if he wants to express "there is no meaningful value", he will always use Nothing. But let's make it official: if Angus writes fromMaybe "", which is accepted by the Haskell compiler but deletes all my files, is he a Haskell programmer? > Say you read something about handguns with safeties being safer than handguns without safeties. Is that an empirical study, or just a salesman saying "it has a safety therefore it's safer!" A safety may provide less safety than other measures, for the same effort. Obviously, using a safety is not much effort. How much effort is required to satisfy the Haskell compiler? And how does that compare to other measures? That is an empirical question. A safety may provide no safety for people who always handle firearms safely. Perhaps bash programmers who always follow conventions (just as true Haskell programmers always follow conventions) in practice would never deploy programs that access uninitialized variables (for example). Where can I find these bash programmers? That is an empirical question. A safety may reduce safety in situations where a firearm must be used quickly. How quickly can a Haskell programmer fix a critical bug when the Haskell compiler reports type errors that would not be runtime errors in a dynamically-typed language? That is an empirical question. A safety may induce risk-compensation. Perhaps Haskell programmers often throw caution to the wind, believing that Haskell programs are more likely to be correct anyway, no empirical evidence needed! How many Haskell programmers believe that? That is an empirical question, but obviously there are quite a few :-p > But some languages are safer than others by design. What do you mean by "safer" here? Let's say "type-safety" means "a type-checker enforces some constraints" and "practical-safety" means "more likely to be correct, all else being equal". It seems you think "type-safety" == "safety" == "practical-safety", by definition. > Haskell is safer than Ruby By how much? How much more, exactly, are Haskell programs likely to be correct?

the_af 12y ago

> perhaps the cost of using Haskell, of satisfying the compiler, of fixing type errors that would not be (runtime) errors in a dynamically-typed language, perhaps that cost outweighs any benefit that type-checking may provide. That's completely irrelevant to the current discussion. We are not discussing convenience; we're discussing safety. Are you trying to de-rail the debate? :) By the way, because you're intent on "teaching" me what deduction and induction mean: not that it has anything to do with the argument at hand, but deductive reasoning (when you can apply it) trumps inductive. > > Yes, fewer failure modes -> increased probability of correctness. > That's an interesting hypothesis. That's... uh... that's not an hypothesis. Something that can fail in fewer ways is safer than something that can fail in more varied ways, all else being equal. There is no need for inductive reasoning here. > BTW, have you not heard "no true scotsman" before? I have, and I have also noticed you were trying to sarcastically invoke this fallacy all along. Unfortunately, it seems you've misunderstood it: No True Scotman applies when you make an assertion, then you're presented with a contradiction, and in order to counter it you adopt an ad hoc assertion which serves as an exception. The fallacy doesn't apply when the assertion is not ad hoc, but in fact that which defines the original assertion. Haskell programmers program using Maybe, that's not a "No True Scotman" fallacy. For example, if I said "Haskell programmers do X", and you say "that's not true for Haskell programmers using Ruby!" and I counter "I was talking about Haskell programmers using Haskell", that's not a case of No True Scotman. It's the same for Haskell programmers using the Maybe monad. Let me explain the kind of flawed reasoning you've been using so far. Say you read something about handguns with safeties being safer than handguns without safeties. You start "blah blah inductive reasoning no true scotman yadda yadda". When someone counters, "well, are you saying handguns with safeties designed to make them safer are not actually safer than handguns without safeties?" your reply seems to be "well, if you give the handgun with safety to a kid, load the gun, switch the safety off, and tell the kid to pull the trigger, then it's not safer!". Do you see the ridiculousness of your position? Any Turing complete language can be used improperly and cause harm. But some languages are safer than others by design. Not better, merely safer. For example, Haskell is safer than Ruby :)

infraruby 12y ago
> We are not discussing convenience; we're discussing safety. We were discussing whether Haskell programs are more likely to be correct (than bash programs), all else (including convenience) being equal. Who is more likely to write correct programs, for the same effort: a Haskell programmer or a bash programmer? Did you think we should allow the Haskell programmer more time, to satisfy an inconvenient type-checker? > you make an assertion, then you're presented with a contradiction, and in order to counter it you adopt an ad hoc assertion which serves as an exception. That is exactly what you did! You said "Haskell uses Maybe", I said "A Haskell programmer could [do something else]" and then anticipated a no true Haskell programmer fallacy, but you went right ahead anyway: the programmer who chooses to use fromMaybe has to decide what the actual default is, and since he has to consciously pick one, he will choose a useful one. Also, because he is using Haskell, if he wants to express "there is no meaningful value", he will always use Nothing. But let's make it official: if Angus writes fromMaybe "", which is accepted by the Haskell compiler but deletes all my files, is he a Haskell programmer? > Say you read something about handguns with safeties being safer than handguns without safeties. Is that an empirical study, or just a salesman saying "it has a safety therefore it's safer!" A safety may provide less safety than other measures, for the same effort. Obviously, using a safety is not much effort. How much effort is required to satisfy the Haskell compiler? And how does that compare to other measures? That is an empirical question. A safety may provide no safety for people who always handle firearms safely. Perhaps bash programmers who always follow conventions (just as true Haskell programmers always follow conventions) in practice would never deploy programs that access uninitialized variables (for example). Where can I find these bash programmers? That is an empirical question. A safety may reduce safety in situations where a firearm must be used quickly. How quickly can a Haskell programmer fix a critical bug when the Haskell compiler reports type errors that would not be runtime errors in a dynamically-typed language? That is an empirical question. A safety may induce risk-compensation. Perhaps Haskell programmers often throw caution to the wind, believing that Haskell programs are more likely to be correct anyway, no empirical evidence needed! How many Haskell programmers believe that? That is an empirical question, but obviously there are quite a few :-p > But some languages are safer than others by design. What do you mean by "safer" here? Let's say "type-safety" means "a type-checker enforces some constraints" and "practical-safety" means "more likely to be correct, all else being equal". It seems you think "type-safety" == "safety" == "practical-safety", by definition. > Haskell is safer than Ruby By how much? How much more, exactly, are Haskell programs likely to be correct?