0

Why is it that some languages don't even have a boolean type (and uses a constant TRUE instead), but they have many other and modern types? Sometimes it can be trouble if you make a boolean and then realize it can have three different values or more, then it's going to be difficult if you have old data with the boolean variable. What are some other reasons to avoid boolean variables?

Related question: https://stackoverflow.com/questions/2426000/why-didnt-c-have-a-boolean-data-type-prior-to-c99

I'm thinking more of conceptual problem like undecidable cases and synchronization problems. And that a boolean often is redaundant information and therefore it can be problems and synchronization issues.

For a semaphore a boolean could be good but maybe not as an instance variable for an account whether or not the account is "P" since that may be different in different ways one might not have thought of, for example when you realize that there are not only two mutually exclusive states for what you are modelling.

closed as unclear what you're asking by gnat, Bart van Ingen Schenau, Jörg W Mittag, TMN, Blrfl May 5 '16 at 15:38

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Can you be a bit more specific which languages you are referring to? Often there are historical reasons, but that depends on the specific languages. – Bart van Ingen Schenau May 5 '16 at 6:05
  • 3
    Surely the related question explains it quite well? Memory addressing is done by byte or word rather than bit – Ewan May 5 '16 at 7:34
  • 1
    Booleans, almost universally, represent derived state from some question (ie, array.isEmpty(), object.equals(...), etc). Couple that with advice in Clean Code like, "don't use Boolean flag parameters", and I've come to the general conclusion that programmers probably shouldn't be passing or storing them, only returning them; in most cases, you probably want some sort of Enum or limited-instantiation type. – Clockwork-Muse May 5 '16 at 9:02
  • 1
    In the case C it's simply due to the incompetence of the designers. – CodesInChaos May 5 '16 at 9:20
  • 1
    @RobbieDee So? Pascal is even older and it has proper bools. (And it also avoided most of the other dumb design decisions C has. The C designers lead my list of "did the most damage to the field of software development") – CodesInChaos May 5 '16 at 10:19
1

This boolean problem is not only related to programming itself. Databases have the same issue in representing boolean values.

Example:

Where MS Access uses -1 as true or yes like VB (see Robbie's answer), MySQL assumes that all except 0 is true.

Transferring data from one database system to another or queries with keywords like true or false can result in strange things.

2

I've never really heard of booleans as being "bad" - as for interfacing with languages (such as in Robbie's answer), it doesn't really matter what type you're working with, you're probably going to need some conversion somewhere.

Moving between the barriers of languages always calls for care in how the values are mapped. Passing an integer value from VBA as supposed to be representing a boolean is an amateur mistake and it should be known that explicit type casting before submitting across the boundary is a good practice. IMO, this has little to do with any specific type being not good to use (it'd be the same case if a VBA integer were passed to a C int (which is a Long in VBA) - it wouldn't make it so "integers are bad", it's just something else we have to be careful of).

I'm not even really sure how we'd work without a language that can't resolve something down to a boolean type of some sort. Every equality comparison expression returns a boolean.

Are strings bad because their low level implementation is hidden from higher level languages? Do we avoid them as such? No, we just try to be aware of the differences between languages and understand the implications and program accordingly (which usually amounts to nothing out of the oridinary). I don't see why we'd treat boolean values any differently.

1

You can hit problems when interfacing between languages that support a boolean such as Visual Basic and legacy languages which don't.

We hit a nasty bug many years ago when a junior developer passed an integer representation of a boolean value in VB to a C DLL. The C DLL was of course expecting >=1 to be true and everything else false, but under the hood true in VB is actually -1.

EDIT:

Things get even more interesting if you have a nullable boolean as you can in C#. We've been doing our first test to a third party API just now and we are again getting -1 back in the XML response. We think that might mean true but can't be sure and the developer in question is off sunning himself somewhere. This leads to the point many here have intimated at: it isn't enough to define the type, you also need to agree on representations when those values cross boundaries. Simply saying non-zero isn't false just doesn't cut it here...

  • 7
    never assume 1 is true. 0 is false, everything else is not false. – gbjbaanb May 5 '16 at 8:07
  • @gbjbaanb That is exactly the point. True and false are irrefutable but various languages have their own take on what numeric value they can be cast to (if they can be cast at all). – Robbie Dee May 5 '16 at 8:21
  • I would suggest that the moral of this specific tale is to be extremely careful when using languages that lack boolean types. Your C library, because it did not use a well-defined boolean type, was hard to interface (and some would even say buggy). That's the fault of C, not VB. – Jules May 5 '16 at 8:47
  • 1
    @Jules It's actually not even the fault of C, the fault lies with the library, and with the library alone. As gbjbaanb said: In C, zero is false, everything else is true. It's the library's input expectations that violates this rule. If the library had stuck to the C rule, there would not have been a problem. In C, if you want to rely on the numeric value of a "boolean", you must use something like !!myBool, failure to do so is always a bug. – cmaster May 5 '16 at 9:21
  • 1
    Yea, nullable bools... I wasn't even going to go there! – jleach May 5 '16 at 14:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.