4 ms·

> I've shown how the compiler helps more. If the Haskell programmer uses Maybe, but there is also a cost to doing that, and overall that approach may (or may n

> I've shown how the compiler helps more. If the Haskell programmer uses Maybe, but there is also a cost to doing that, and overall that approach may (or may not) help more in writing correct programs than using bash with a test suite using "set -u". > The rest of your comment reads like a confused mess to me. You have two options: 1. you can make deductive claims like "if it compiles then it works" which require proof; or 2. you can make inductive claims like "more likely to be correct (all else being equal)" which require empirical evidence. You appear to be offering deductive arguments for an inductive claim.

the_af 12y ago
> If the Haskell programmer uses Maybe, but there is also a cost to doing that No, no ifs about it. Haskell uses Maybe to denote the absence of a value; this is a fact. There is no other possibility because the language doesn't have null values. If there to a cost in using Maybe, it's definitely not paid in safety/correctness, which is what we're discussing here. You continue to write "may or may not" but I've shown you how the approach is better than bash. You can even forget the Maybe monad if you're less experienced with it, and instead focus on one simple fact: you can write and run a bash program that aborts after attempting to access an undeclared variable, but you cannot write and run such a program in Haskell because it's impossible. Haskell is safer. Deductive/inductive is neither here nor there. I didn't make the ridiculous claim that "if it compiles then it works", and nobody else here did either. The claim I did make is that entire failure modes which are present in bash aren't possible in Haskell; I leave to you as an exercise to consider whether there exist failure modes in Haskell which are not in bash.
- infraruby 12y ago
  > Haskell uses Maybe to denote the absence of a value A Haskell programmer could use an empty string for that, or given a Maybe could do this: fromMaybe "" But no true Haskell programmer would do that. > you can write and run a bash program that aborts after attempting to access an undeclared variable Yes, and perhaps the bash programmer could likely eliminate that fault through testing, perhaps about as likely as the Haskell programmer could get the Haskell compiler to accept a program at all! > The claim I did make is that entire failure modes which are present in bash aren't possible in Haskell And therefore Haskell programmers are more likely to write correct programs?
  - the_af 12y ago
    > A Haskell programmer could use an empty string for that, or given a Maybe could do this: fromMaybe "" Do you see how that's totally unrelated to accidentally accessing an uninitialized variable? In one case, you have an unforeseen event, usually caused by a typo; because the programmer didn't plan for this, the program will abort, crash or launch nuclear missiles, depending on the non-statically typed language of your choice. In the other case, 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. Feel free to reply to this with yet another snark, but it will only show you're unfamiliar with the subject under discussion. > perhaps the bash programmer could likely eliminate that fault through testing, perhaps about as likely as the Haskell programmer could get the Haskell compiler to accept a program at all! No. 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. Note: safer, not necessarily better. I'm not saying Haskell is "better" than Ruby, if that's why you're being so defensive about this: there are valid reasons why one would choose a language which offers fewer guarantees of correctness (i.e. there are "safer" languages than Haskell, and valid reasons not to pick them as well). > > The claim I did make is that entire failure modes which are present in bash aren't possible in Haskell > And therefore Haskell programmers are more likely to write correct programs? Yes, fewer failure modes -> increased probability of correctness. My advice to you: stop being sarcastic, because it's not helping your argument. Also, how many Haskell programs have you written, or at least code reviewed, since you're so sarcastic about how a "true" Haskell programmer writes code?
    - infraruby 12y ago
      > 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?
- deleted 12y ago
  [deleted]

the_af 12y ago

> If the Haskell programmer uses Maybe, but there is also a cost to doing that No, no ifs about it. Haskell uses Maybe to denote the absence of a value; this is a fact. There is no other possibility because the language doesn't have null values. If there to a cost in using Maybe, it's definitely not paid in safety/correctness, which is what we're discussing here. You continue to write "may or may not" but I've shown you how the approach is better than bash. You can even forget the Maybe monad if you're less experienced with it, and instead focus on one simple fact: you can write and run a bash program that aborts after attempting to access an undeclared variable, but you cannot write and run such a program in Haskell because it's impossible. Haskell is safer. Deductive/inductive is neither here nor there. I didn't make the ridiculous claim that "if it compiles then it works", and nobody else here did either. The claim I did make is that entire failure modes which are present in bash aren't possible in Haskell; I leave to you as an exercise to consider whether there exist failure modes in Haskell which are not in bash.

infraruby 12y ago
> Haskell uses Maybe to denote the absence of a value A Haskell programmer could use an empty string for that, or given a Maybe could do this: fromMaybe "" But no true Haskell programmer would do that. > you can write and run a bash program that aborts after attempting to access an undeclared variable Yes, and perhaps the bash programmer could likely eliminate that fault through testing, perhaps about as likely as the Haskell programmer could get the Haskell compiler to accept a program at all! > The claim I did make is that entire failure modes which are present in bash aren't possible in Haskell And therefore Haskell programmers are more likely to write correct programs?
- the_af 12y ago
  > A Haskell programmer could use an empty string for that, or given a Maybe could do this: fromMaybe "" Do you see how that's totally unrelated to accidentally accessing an uninitialized variable? In one case, you have an unforeseen event, usually caused by a typo; because the programmer didn't plan for this, the program will abort, crash or launch nuclear missiles, depending on the non-statically typed language of your choice. In the other case, 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. Feel free to reply to this with yet another snark, but it will only show you're unfamiliar with the subject under discussion. > perhaps the bash programmer could likely eliminate that fault through testing, perhaps about as likely as the Haskell programmer could get the Haskell compiler to accept a program at all! No. 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. Note: safer, not necessarily better. I'm not saying Haskell is "better" than Ruby, if that's why you're being so defensive about this: there are valid reasons why one would choose a language which offers fewer guarantees of correctness (i.e. there are "safer" languages than Haskell, and valid reasons not to pick them as well). > > The claim I did make is that entire failure modes which are present in bash aren't possible in Haskell > And therefore Haskell programmers are more likely to write correct programs? Yes, fewer failure modes -> increased probability of correctness. My advice to you: stop being sarcastic, because it's not helping your argument. Also, how many Haskell programs have you written, or at least code reviewed, since you're so sarcastic about how a "true" Haskell programmer writes code?
  - infraruby 12y ago
    > 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?
deleted 12y ago
[deleted]