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!
- 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.