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 :-)