6 ms·

> We are not discussing convenience; we're discussing safety. We were discussing whether Haskell programs are more likely to be correct (than bash programs), a

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

the_af 12y ago

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.