> 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?
> 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?
> 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 :)
> 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?
Your post can be pretty much answered with a big "no".
- No, we were talking about safety, not convenience. Stop shifting the subject. (But do you know what IS inconvenient? Being hit by a bug on production in your Ruby program that could have been prevented by a static type checker).
- No, this is not a case of No True Scotsman. First, you seem to misunderstand how fromMaybe is used (have you EVER programmed in Haskell?). Unlike other languages, where null can hit you by surprise, the programmer ALWAYS chooses the default value for fromMaybe. Since HE chooses it, it's not an accident. It can never happen by accident, as with null. Repeat after me: this. is. not. a. case. of. the. no. true. scotsman. fallacy. "So there is this Scottish guy..." "Wait, what if this is a Scotsman from Mars?" "But Scotsmen are from Scotland!" "A-HA! Fallacy!" This gets old fast.
- No, a programming language with additional safeties is logically safer than one without, all else being equal (i.e. if no other safeties get removed instead). Especially since those safeties don't prevent you from also applying every engineering practice from the other, no-safe language. You can do all the fancy testing you do for your Ruby programs in Haskell as well! In fact, a lot of interesting testing tools have come from the Haskell community, such as QuickCheck (aka property testing). In fact, it wouldn't surprise me if there was a RubyCheck nowadays.
- No, Haskell programmers aren't smug fools who believe that because their programs compile then they must be correct, and therefore no additional testing or QA is necessary. You keep bringing this old nonsense up, and you're the only one who believes it. Please accept as a given that no-one believes this and never bring it up again.
> 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.
Actually, rather than being equal, what I think is that an increase in one implies an increase in the other. A type-checker enforcing some constraints automatically makes your language practically safer than one without it. It's yet another tool in your toolset, one that gets automatically applied by the compiler. I get that, by convenience, some people want to write programs without some safeties; that's an issue of convenience, which is separate.
> Obviously, using a safety is not much effort. How much effort is required to satisfy the Haskell compiler?
Not much. Haskell programmers everywhere do it daily. What's your point? Have you written a program in Haskell and found it too hard?
Please think before you want to lecture me again about deductive and inductive reasoning. You sound condescending instead of clever.
I refuse to discuss this with you any further until you drop the sarcasm and answer this simple question: how fluent are you with Haskell? If you claim to have actual Haskell programming experience (tutorials don't count) I'll take your word for it, accept that you understand its trade-offs, and let you have whatever last word you want to have in this subject, and move on.
> - No, we were talking about safety, not convenience.
If you don't want to compare programs written for the same effort, then what? Should we compare Haskell programs written with more effort to bash programs written with less effort? That's a confounding variable!
For the programmer there is always an opportunity cost: an hour spent satisfying a type-checker is an hour that could have been spent testing. Which use of that hour would provide the greatest safety? That is an empirical question.
> Stop shifting the subject.
No, you keep shifting the subject when you claim that Haskell programs are safer in practice but you then run away to your wonderland, where time stands still and the problem of opportunity cost has been solved, where you "prove" whatever you like while detached from reality, and then return to pretend that your "proofs" are valid in practice!
> - No, this is not a case of No True Scotsman.
So... if Angus writes fromMaybe "", which is accepted by the Haskell compiler but deletes all my files, is he a Haskell programmer?
> - No, a programming language with additional safeties is logically safer than one without, all else being equal (i.e. if no other safeties get removed instead).
Oh, "logically"! It's amazing what you can "prove" when you postulate a magical language that stops the clock while you satisfy the type-checker! Unfortunately, on this planet, time waits for no man, and you must choose how you spend it. Which approach provides the greatest safety, for the same effort? That is an empirical question, and you still have no empirical evidence for your position.
> - No, Haskell programmers aren't smug fools who believe that because their programs compile then they must be correct, and therefore no additional testing or QA is necessary.
No, you just believe you don't need empirical evidence for empirical claims! :-/
> A type-checker enforcing some constraints automatically makes your language practically safer than one without it.
Perhaps. But perhaps the time spent satisfying a type-checker would be better spent testing. Perhaps bash is safer than Haskell in practice!
> perhaps the time spent satisfying a type-checker would be better spent testing
One of the reasons I like languages with more advanced types systems such as Haskell's or Scala's is because test suites in other languages to achieve the same code coverage take much longer to run.
> One of the reasons I like languages with more advanced types systems such as Haskell's or Scala's is because test suites in other languages to achieve the same code coverage take much longer to run.
Do you mean Haskell has better runtime performance than dynamic languages, test for test, or that programs in dynamic languages need more tests (say, tests of function return types), or both?
In practice programs are written by programmers, not generated randomly, so it is not necessary to test "all the things that can go wrong" but only the things that programmers actually do wrong in practice.
So you refused to answer my direct question: how fluent are you with Haskell? I must assume the answer is "not much", which is why you keep building strawmen and disregarding everything people tell you about the language.
For an empirical advocate, you keep arguing from a quite theoretical point of view.
> So... if Angus writes fromMaybe "", which is accepted by the Haskell compiler but deletes all my files, is he a Haskell programmer?
He is a Haskell programmer, the same as any Haskell programmer that runs launchAllNukes. What he is not is a surprised Haskell programmer, unlike someone, say, a programmer using bash or a programming language which allows nulls and/or accessing undefined variables with surprising results.
Why is Angus not surprised? Well, because he chose to return "" when he had Nothing. Presumably he thought the empty string was an acceptable value, and he wasn't trying to indicate "no value", because that is what Haskell programmers use Maybe for (and please don't mention Scotsmen here, because it will only make you seem ignorant). If his choice turned out to cause a bug, he made a mistake. But note this is unlike the situation for Mr Bash, who didn't choose to access an undefined variable, and unlike Mr Java Dev, who didn't choose to ignore a possible null return value. This is because Haskell is safer than bash or Java: Angus, Mr Bash and Mr Java can all make mistakes when choosing default values, but unlike the other two, Angus cannot make the mistake of accessing an uninitialized variable or a null reference. He is lucky like that!
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?