Java’s Broken Booleans

[Lawrence D'Oliveiro]

On Tue, 15 Feb 2011 15:14:24 +1300, Lawrence D'Oliveiro



Anal retentive IS GOOD in computer programs.

Sure. And Pascal managed to be that while actually offering a more useful
boolean type than Java can muster.

 

[Lawrence D'Oliveiro]

All Basic variants I have touched in the 80s used -1 for true and 0 for
false. Visual Basic still does it that way.

It’s a stupid thing to do.

Any way it seems quite stupid to write A <= B if you actually mean !A ||
B.

Funny you word it like that: mathematically the two are equivalent, you
don’t “mean†one or the other, they both “mean†the same thing. That’s what
“mean†means.

If any programmer in my team did such a thing I would certainly kick
his butt.

Remind me never to hire you.

 

[Lawrence D'Oliveiro]

And look at the hole you end in. Bad choice, bad reason.

What hole would that be, then?

And this important case is handled nicely by the general code.

I think you’re confusing circular buffers with double-buffering. Double-
buffering only ever needs two buffers.

 

[Lawrence D'Oliveiro]

For Boolean algebra any domain of 2 values will do, Larry.

Completely ignoring the rest of what I said, Arvy.

 

[Lawrence D'Oliveiro]

Exactly - good choice by Java.

First you say it is good ...

It keeps the language simple but loose a bit of type safeness.

It is as it is.

.... and then you admit that there is no good reason for it.

That seems to be characteristic of the responses here when I point out
deficiencies and mistakes in Java or its specification. It’s like Java is
all you know, you have no standard of comparison with other languages, even
other common ones—no sense of perspective on how things should be done
versus how your favourite language does them.

It’s like I’ve blundered into some kind of cosy mutual wankfest.

 

[Lawrence D'Oliveiro]

You are wrong about Java. It does impose an ordering and it is just as
you wish:
http://download.oracle.com/javase/6/docs/api/java/lang/Boolean.html#compareTo(java.lang.Boolean)

boolean a, b, c;
a = b <= c;

test.java:6: operator <= cannot be applied to boolean,boolean
a = b <= c;
^
1 error

Nope, still doesn’t work. Care to try again?

As far as "they all do" goes, well…that's almost certainly false. It
takes only one language to disprove.

Go on, then—disprove it.

 

[Joshua Cranmer]

no sense of perspective on how things should be done
versus how your favourite language does them.

Recalling your recent complaints about Java generics not being C++, I
believe that this statement could very well be applied to you: just
because C++ does it doesn't mean it's how it should be done.

The entire argument pretty much boils down to "should booleans be
treated as an integer type?" Java decided no, and you assert that it's
broken as a result. There's really no compelling reason to treat
booleans as integers (effectively, it's an implementation detail) other
than that it saves keystrokes in certain (probably) rare circumstances.
On the flip side, there's also really no compelling reason to not treat
them as integers--but it does make things safer at compile-time.

It’s like I’ve blundered into some kind of cosy mutual wankfest.

So trying to defend a design decision is a "cosy mutual wankfest"? I
suppose I need to brush up on these new euphemisms...

 

[Arne Vajhøj]

boolean a, b, c;
a = b<= c;

test.java:6: operator<= cannot be applied to boolean,boolean
a = b<= c;
^
1 error

Nope, still doesn’t work. Care to try again?

Care to try click on his link and read it?

Go on, then—disprove it.

He practically did.

But obviously it requires ability to click on a link
and read English to understand it.

Arne

 

[Lew]

Joshua Cranmer wrote:

It’s like I’ve blundered into some kind of cosy [sic] mutual wankfest.

So trying to defend a design decision is a "cosy mutual wankfest"? I suppose I
need to brush up on these new euphemisms...

"It’s like I’ve blundered into some kind of cosy [sic] mutual wankfest."

translates to:

"I'm a worthless troll."

 

[Lew]

Care to try click on his link and read it?


He practically did.

But obviously it requires ability to click on a link
and read English to understand it.

He might, had he a brain, also wish to take note of the observation that the
ordering applies to 'Boolean', not 'boolean', and uses 'compareTo()', not '<='.

However, lacking the prerequisite, he won't.

 

[Lew]

In any case, I have drifted from the original thread. I suggest: If you
like ?: , go ahead and use it. Just be judicious.

I'm in complete accord with your suggestion.

?: never was intended for complex or lengthy expressions, not even in C. It's
a convenience for situations such as the one you posited upthread, a simple
conditional expression that would otherwise require a whole other method.

Obviously the choice balances the cost (however you perceive it) of the one
idiom against the other. When, as in the situations you described, the cost
of the ?: exceeds the cost of the method, or the method's benefits really
start to pay off, you eschew the operator and go with the method.

In your example, the expression was so simple that the cost of relocating a
reader's attention to a separate method lacked the advantage over the tight
grouping of a simple decision operator expression. Or perhaps in real life
the factory method's advantages are strong even here.

Joshua Bloch's /Effective Java/, Item 1, is, "Consider static factory methods
instead of constructors". It is not, "Use static factory methods instead of
constructors".
http://java.sun.com/docs/books/effective/

One (among several) motivation for factory methods is opacity - to hide
implementation (example: Collections.unmodifiableMap()). Another is
self-documentation - the name reveals what you're getting (same example).
Other times you have less need for what factories provide, or even want to
reveal some things about implementation (HashMap). Then you use a constructor
- it hurts nothing and it's simpler than dealing with tons and tons of factory
methods. Sometimes you feel like a nut, sometimes you don't.
http://en.wikipedia.org/wiki/Mounds_(candy)

So as Ian said, be judicious.

 

[Arved Sandstrom]

Completely ignoring the rest of what I said, Arvy.

I don't believe I did ignore anything you said. I simply think you're
still fixated on a numerical {integer 0, integer 1} representation of
Booleans, and I'm attempting to keep the discussion steered away from that.

Forget about calling the operations "addition" and "multiplication".
Just call them "disjunction" and "conjunction", and forget about the
fact that _one_ possible representation of the Boolean domain is
{integer 0, integer 1}. Seriously wrap your head around two opaque
symbols T and F, and consider those to be the only Boolean domain you
need to worry about.

If you still believe that Booleans have a natural ordering then you're
still thinking {0,1}.

And Galois fields? Give me a break. If you were competent to talk about
the fine details of Galois fields then I'd also expect to see you
finetuning Haskell arrow implementations, not hacking in C and C++ and Java.

AHS

 

[Paul Cager]

Go on, then—disprove it.

COBOL
S3
Algol 60 (?)
.....

 

[Arved Sandstrom]

He might, had he a brain, also wish to take note of the observation that
the ordering applies to 'Boolean', not 'boolean', and uses
'compareTo()', not '<='.

However, lacking the prerequisite, he won't.

I'm pretty sure he did notice the difference, and is just being a piss
artist. I predict that next we'll hear complaints about Java not having
operator overloading.

AHS

 

[Andreas Leitgeb]

If you still believe that Booleans have a natural ordering then you're
still thinking {0,1}.

Nonsense. A truth is "naturally" worth more than a lie.
There may not be a "natural" mapping to particular numbers,
but there *is* a natural ordering on truth values.

As has been pointed out already a few times, there even is
a natural ordering on Booleans in Java, just not on booleans.

 

[Silvio]

It’s a stupid thing to do.


Funny you word it like that: mathematically the two are equivalent, you
don’t “mean†one or the other, they both “mean†the same thing. That’s what
“mean†means.

Mathematically there are no such symbols at all so that is utter nonsense.
Besides, since the thread was about Java versus C++ programming the word
'mean' should obviously be interpreted as referring to Java/C++ syntax.
I suspect you understood that but simply chose to be an ass-whole.

Both expressions just happen to evaluate to the same result in C++ based
on the numerical values C++ uses to represent true and false.

You hopefully also know that might A or B have observable side effects
!A||B has defined behavior while A<=B does not.

Remind me never to hire you.

Don't worry, you will never be in that position.

 

[Lew]

If you still believe that Booleans have a natural ordering then you're still
thinking {0,1}.

Your conclusion is predicated on the assumption that he's thinking. That is
not a safe premise.

 

[Lew]

Nonsense. A truth is "naturally" worth more than a lie.

Nonsense. A lie is worth more than the truth. It's much costlier. Of
course, such a judgment is royally irrelevant to Java.

There may not be a "natural" mapping to particular numbers,
but there *is* a natural ordering on truth values.

Utter nonsense. There's nothing "natural" about such an arbitrary ordering.

As has been pointed out already a few times, there even is
a natural ordering on Booleans in Java, just not on booleans.

That is not factually correct. In Java, there is no ordering on 'boolean',
only on 'Boolean'. As has been pointed out already a few times.

 

[Lew]

I'm pretty sure he did notice the difference, and is just being a piss artist.

He's just being a pisshead.

I predict that next we'll hear complaints about Java not having operator
overloading.

I won't "hear" him unless one of you quotes him. He's a tool; stop answering him.

 

[Lew]

Silvio wrote:

Mathematically there are no such symbols at all so that is utter nonsense.
Besides, since the thread was about Java versus C++ programming the word
'mean' should obviously be interpreted as referring to Java/C++ syntax. I
suspect you understood that but simply chose to be an ass-whole.

Both expressions just happen to evaluate to the same result in C++ based on
the numerical values C++ uses to represent true and false.

You hopefully also know that might A or B have observable side effects !A||B
has defined behavior while A<=B does not.

I finally understood why people were saying "A <= B" instead of "A -> B". I
have never seen anyone attempt to use "<=" as a logical operator before, not
even in C. It's weird, not least because "<=" visually reverses the direction
of the implication arrow.

I don't expect anything less misguided from "Lawrence D'Oliveiro", though.

Don't worry, you will never be in that position.

I don't think "Lawrence D'Oliveiro" understands metaphor, or much else.