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.

Community
  • 1
Niklas Rosencrantz
  • 8,008
  • 17
  • 56
  • 95
  • 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 05 '16 at 06:05
  • 3
    Surely the related question explains it quite well? Memory addressing is done by byte or word rather than bit – Ewan May 05 '16 at 07: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 05 '16 at 09:02
  • @Clockwork-Muse I agree. It's almost always redundant when you have a boolean. – Niklas Rosencrantz May 05 '16 at 09:12
  • 1
    In the case C it's simply due to the incompetence of the designers. – CodesInChaos May 05 '16 at 09:20
  • @CodesInChaos Er...what!?! You do realise how long ago C was written don't you? – Robbie Dee May 05 '16 at 09:55
  • 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 05 '16 at 10:19
  • @CodesInChaos I'll save us a few pages and cede that NULLs are a bad idea, buffer overruns suck and by golly, isn't it a terrible language for the internet. It isn't perfect, it wasn't at the time - it was a veritable curate's egg. But many of today's languages are heavily based on it. We all stand on the shoulders of giants. – Robbie Dee May 05 '16 at 10:42
  • @CodesInChaos [Related](http://programmers.stackexchange.com/questions/114846/why-has-c-prevailed-over-pascal) – Robbie Dee May 05 '16 at 10:44
  • 1
    @RobbieDee Algol 60 had booleans much, much earlier. – microtherion May 05 '16 at 13:51
  • @microtherion I was making the point that it is foolhardy to compare the languages of yesteryear to the demands of today's programmers. And C was never "missing" a boolean type - it simply wasn't required due to the [design of the language](http://stackoverflow.com/a/2429581/1371040). If you *did* want it, you could implement it in one line. C99 has it as standard too. – Robbie Dee May 05 '16 at 14:51
  • "true" is old fashioned? Pity you cannot say the same for "false". – James Anderson May 05 '16 at 15:36
  • 1
    It is silly to act as if design decisions made for modern languages could be transparently applied to a language designed for machines that came with 16kb RAM, yet people constantly do. – Gort the Robot May 05 '16 at 15:46
  • @StevenBurnap 16kb RAM is about 20 000 lines of code isn't it? That's a lot. – Niklas Rosencrantz May 05 '16 at 16:06
  • You think each line of code compiles to less than a byte? – Gort the Robot May 06 '16 at 01:54

3 Answers3

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.

jleach
  • 2,632
  • 9
  • 27
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...

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 7
    never assume 1 is true. 0 is false, everything else is not false. – gbjbaanb May 05 '16 at 08: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 05 '16 at 08: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 05 '16 at 08:47
  • @Jules Yes, I'm not putting this out there as a shining beacon of coding practice, I'm merely responding to the OP... – Robbie Dee May 05 '16 at 08:54
  • 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 - reinstate monica May 05 '16 at 09:21
  • Attended to a typo... – Robbie Dee May 05 '16 at 11:23
  • 1
    Yea, nullable bools... I wasn't even going to go there! – jleach May 05 '16 at 14:52
  • @jdl134679 Yep, "let's introduce the problems of reference types to value types..." – Robbie Dee May 05 '16 at 14:55
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.

Clijsters
  • 128
  • 6
  • 1
    The underlying representation is unimportant, since you can run into similar problems with any type (character-based data having major problems). – Clockwork-Muse May 05 '16 at 08:47
  • 1
    That's a good answer. Did you read this http://thedailywtf.com/articles/Special-Delivery – Niklas Rosencrantz May 05 '16 at 09:11
  • 1
    @Programmer400 Nice :) It seems that this happens often. – Clijsters May 05 '16 at 09:41
  • 1
    "all except 0 is false"!? Is that what you meant? http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html BOOL, BOOLEAN These types are synonyms for TINYINT(1). A value of zero is considered false. Nonzero values are considered true: – Mike May 05 '16 at 14:21