[Haskell-cafe] Bool is not...safe?!

[Joachim Durchholz]

Hi,

the criticism is valid but mostly irrelevant.
> There is an opinion that Bool type has problems. It's "dangerous", 
> because it's not good to be used as flag for success/fail result.

Actually that's the one good use case.
Also, Boolean-as-a-type means that you do not need a separate language 
concept of Condition, Conditions are just those Expressions that happen 
to be of type Boolean. And suddenly you can write functions that operate 
on Conditions, or define operators for them (if the language allows 
operator definitions), etc.

> I read this post: 
> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/

Well, the first two paragraphs are just overgeneralizations of personal 
observations.

> and was shocked. How popular is such opinion?

It's a fringe opinion. Most people don't even think about whether 
Boolean is an appropriate type.

 > Is it true, that bool is "bad" type?
> 
> As I understand arguments of the post, Bool is bad because: 1) you
> don't know what does True/False mean  2) after comparison you get bit
> (!) only but then you may need to  "recover" the comparing value
> which was "shrink" to bit already.

Sure. That's a valid point the post is making.
So you shouldn't move the creation of a Boolean too far away from its 
consumption.

The same argument holds for any numeric data type; if you pass around 
Floats, you quickly lose knowledge whether it's yards or meters (that 
kind of problem actually made an interplanetary probe miss its 
destination planet).

So you simply use whatever the language offers for making binary 
distinctions. In C you use the preprocessor to say PRESENT or ABSENT 
instead of true or false (actually 0 or 1); in Java you use an enum, in 
Haskell you use a data type.

> Really, what does True/False mean? How to find semantic of True? It's
>  very simple, because there is A) contract/interface which interprets
>  True/False and also B) there is a help from science.

This works as long as the contract is easily deducible from the context 
in the program.
I.e. if you have a file-is-open function, then the contract of that 
function says that the result is True or False, and as long as the value 
from the function is kept in contexts where it's clear that we are 
talking about a file-open status, that's good enough.
Things can get nasty when you start moving a file-is-open Boolean into a 
"valid" attribute. You (as a human reader) lose the information that the 
value is related to a file-open status.
Note that such a loss of context may actually be intentional, if the 
goal is to have more abstract code and we don't care anymore whether 
that valid=False status relates to files or whether it's a weekday. 
Though that's exactly the situation where the blog post's arguments are 
irrelevant, too :-)

> *This means that using of False to indicate success - is error!

Not really.
It can mislead a human reader, so it should be avoided. But I have had 
some rare occasions where isFailure: Boolean was the correct declaration 
to use (e.g. if isFailure is False by default - actually that's not a 
too rare situation now that I think about it).

 > And
> no way to miss provenance/knowledge what True or False means.*

Except that if you pass the value to a variable named "isSuccess", you 
have a bug.

> (the same: what does Right/False mean?)

Personally, I avoid the True/False terminology; it (mis)applies the 
concept of "desirable" or "truth", and boolean values aren't about 
desirability or truth.

Just assume the values are "Yes" and "No"; actually this is exactly the 
issue the blog post is really talking about: "Yes" and "No" are answers, 
but answers are useful only as long as you know the question.
(Reminds me of "42" in the Douglas Adams fiction: the supercomputer gave 
that as the ultimate answer, now they are building a larger 
supercomputer to find out what the question to that answer is.)

> B) The help from science.

Science is not too relevant here.
The blog post is talking about maintainability, i.e. programmer psychology.

For Booleans, science tells you a lot about what you can do with them, 
but it does not tell you what the results of your operations *mean*.


> So, my question is: is this post a april 1st trolling or author was 
> serious? :)

The latter, but you missed the point ;-)
(SCNR)

BTW the post is pretty rambling, it touches a lot of points but is never 
quite precise.
I hope I did better but I'll leave that to better judgement than mine :-)