Java’s Broken Booleans

[Andreas Leitgeb]

Nonsense. A lie is worth more than the truth. It's much costlier.

A new definition of "worth", that I wasn't previously aware of.

 

[Lew]

A new definition of "worth", that I wasn't previously aware of.

Your definition is at best obscure. I was using "worth" as "of a certain
cost"; that seems a quite normal definition of "worth". How much is that dog
worth? It's worth what it costs. How is that a new definition?

My point is that it's meaningless to say a "A truth is "naturally" worth more
than a lie." There's no such thing as a "natural worth" to truth or lie, just
your arbitrary (and as yet private) definition of "worth". Would you care to
share your idiolectic definition, please?

 

[Andreas Leitgeb]

Your definition is at best obscure.
I was using "worth" as "of a certain cost";

This I find a rather strange definition, myself. If worth was *defined* as
the price it costs, how could anything possibly "not be worth its price"?

My definition of worth is rather along the value it has for the owner.
(Which, *may* be the price he would get from *selling* it, but doesn't
need to be. In any way the worth is unrelated to the costs of aquiring
or having it.)

My point is that it's meaningless to say a "A truth is "naturally"
worth more than a lie."

My point is, that it isn't.

PS: I intend to let this particular subthread starve, unless you
raise some new truely worthy (haha) aspects...

 

[Lew]

Andreas Leitgeb wrote:

My point is, that it isn't.

PS: I intend to let this particular subthread starve, unless you
  raise some new truely worthy (haha) aspects...

Too bad, because you have yet to describe how you arrive at your
statement. What is that "natural" worth and how does a truth have
more of it than a lie, and what does any of that have to do with Java,
given that the Java boolean and Boolean types have nothing to do with
that kind of truth?

But hey, if you don't feel the need to explain, that's your
privilege.

 

[Lawrence D'Oliveiro]

Mathematically there are no such symbols at all ...

Do you really know that little about Boolean algebra? Are you the type who
goes “WTF†when presented with De Morgan’s theorems?

Maybe you or your team-mates tend to write “if (cond == true)†as well—let
me get a bib for you.

 

[Lawrence D'Oliveiro]

Care to try click on his link and read it?

My compiler doesn’t seem to be convinced by that line of reasoning, it still
won’t let the operator work. Do you want to try shouting louder?

 

[Andreas Leitgeb]

But hey, if you don't feel the need to explain, that's your
privilege.

yep.

 

[Lawrence D'Oliveiro]

This I find a rather strange definition, myself.

DNFTT.

 

[Lawrence D'Oliveiro]

And `A <= B' smells very heavily of code that will make most people go
"WTF?" on first sight, and anyone who uses it in production code should
be shot.

Do you go “WTF?†when presented with De Morgan’s theorems, too? Do you think
anybody who interchanges “not (A or B)†with “not A and not B†should be
shot?

Do you tend to write “if (cond == true)� Let me get a bib for you.

 

[Arved Sandstrom]

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.

There is? I'm no expert on this stuff, but I don't think you get into
this area until you're talking about 2-element Boolean lattices...and
for a real-world java.lang.Boolean that effectively gives us trivalent
logic, and throws an NPE if one of the truth values being compared to is
"unknown", I think it's a bit silly to want FALSE < TRUE.

As Peter Duniho has pointed out, and as I also provided an example for,
there are practical uses for being able to sort on Booleans - practical
in the sense of real-world, down-to-earth programming - and in that
picture it doesn't exactly matter what the ordering of TRUE and FALSE
is, just that there is one.

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

No, there's an artificial ordering on java.lang.Booleans. There's a
difference.

AHS

 

[Joshua Cranmer]

Do you go “WTF?†when presented with De Morgan’s theorems, too? Do you think
anybody who interchanges “not (A or B)†with “not A and not B†should be
shot?

de Morgan's laws are different (especially since you pretty much do
negation of the comparison value when implementing code in assembly, so
distributing the not is vital for compiling code). They are a statement
about boolean entities which are assignable to the notion of true and
false by themselves.

Instead, you propose to replace the statement !A || B with a statement
that is nearly the same effect, but implies that the values are
themselves integral entities as opposed to elements of a finite simple
group of order two.

Do you tend to write “if (cond == true)� Let me get a bib for you.

Sometimes I do, if I really want to emphasize the true part. Most of the
time I don't. You see, I write my code to be *readable* first and fast
second--it's the compiler's job to make my code fast, and unless the
compiler people are idiots, most of the little things I do to make stuff
easy on people's eyes are going to optimized out anyways.

But face it; you're resorting to ad hominems now, which probably means
you have no argument left.

 

[James McCreedy]

DNFTT.

Oh, my God.

 

[Arved Sandstrom]

Do you go “WTF?†when presented with De Morgan’s theorems, too? Do you think
anybody who interchanges “not (A or B)†with “not A and not B†should be
shot?

Do you tend to write “if (cond == true)� Let me get a bib for you.

I think you know damned well that a competent programmer understands De
Morgan's laws; they get used often enough.

What the majority of programmers don't understand are the precise
details of logical implication. If you're not aware of this then you
haven't ever worked on real projects with lots of average programmers.
It's all well and good to be superficially clever, but if it leads to
incomprehensible code and difficult maintenance then you're a negative,
not a positive.

In any case Java is hardly the only language with boolean types that
does not permit this syntax conversion (i.e. !A || B is ok with boolean
types, but A <= B is not).

AHS

 

[Arne Vajhøj]

My compiler doesn’t seem to be convinced by that line of reasoning, it still
won’t let the operator work. Do you want to try shouting louder?

The problem is not in the compiler, but in the programmer
using the keyboard.

Read and fix your code, then it will work.

Arne

 

[Mike Schilling]

Do you go “WTF?†when presented with De Morgan’s theorems, too? Do you
think
anybody who interchanges “not (A or B)†with “not A and not B†should be
shot?

Do you tend to write “if (cond == true)� Let me get a bib for you.

"false" is 0, and "true" is any non-zero number, so it's clear that true is
both smaller than and greater than false.

 

[Andreas Leitgeb]

but there *is* a natural ordering on truth values.

[Arved disagrees]

That's fine with me, but anyway:

The *natural* order may be slightly more obvious after
not-excluding a few of the uncertaincy values:

false unlikely maybe perhaps likely surely true

Satisfied? If not, then so be it.

 

[Michael Wojcik]

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

Here's one: COBOL. Level-88 items let you define the representation of
"true" and "false" for a given variable, so they can have any ordering
you like.

But, hey, it's only the second-oldest HLL still in widespread use,
with millions of SLOC in existence. Can't really expect a Usenet
self-anointed programming-language expert like Lawrence to have heard
of it.

And, of course, there are Turing-complete[1] programming languages
that do not impose any ordering on true and false evaluations. In
Unlambda, for example, the only type is "function"; it is possible to
represent values and compare them, but the results of comparisons are
chosen arbitrarily by the implementor of the comparison functions, and
whether those results are themselves comparable is also up to the
implementor.


[1] In the informal sense popular on Usenet.

 

[Lew]

but there *is* a natural ordering on truth values.

[Arved disagrees]

That's fine with me, but anyway:

The *natural* order may be slightly more obvious after
not-excluding a few of the uncertaincy values:

false unlikely maybe perhaps likely surely true

Satisfied? If not, then so be it.

That's backwards, except for "unlikely", "maybe" and "perhaps".

"surely" == "true".

So the "natural" order is "true likely unlikely maybe perhaps false".

In other words, your so-called "natural" order is arbitrary and, in this case,
clearly unique to you.

 

[Lew]

The problem is not in the compiler, but in the programmer
using the keyboard.

Read and fix your code, then it will work.

In other words, it's operator error.

"Lawrence D'Oliveiro" keeps ignoring the fact that the ordering is on
'Boolean', and tries to refute that fact by citing 'boolean'. He seems to be
unable to tell the difference between 'Boolean' and 'boolean', which for most
intents and purposes are not equivalent. Someone should clue "Lawrence
D'Oliveiro" in to the fact that Java is case sensitive.

 

[Andreas Leitgeb]

So the "natural" order is "true likely unlikely maybe perhaps false".

So at least you finally admit the *existence* of a natural order ;-)
(getting the sequence right will be the next task, next year, perhaps)