I know I'm biased by familiarity, but I really like that 0 is truthy in Ruby. I often find that I want to check whether there is a number there at all, whether it is 0 or not, and a truthiness test works well for that.
Is there a good reason, other than expectations brought from other langs, why 0 should be falsey?
0 for false goes all the way back to Boole. He used multiplying for AND and adding for OR. You can also think of a Boolean as an index into a list of choices: “if t then c else a” could be written “[a, c][t]”. This is sometimes a good way to think about booleans, not just a hack: for instance it leads you to multiway decision diagrams to generalize BDDs.
I like the line in the Zen of Python, "Explicit is better than implicit."
You should get a type error if you try to use an int in boolean logic. I hate auto type-conversion. Autoboxing in Java is kinda nice, but really the base types should have been objects to begin with, and operator overloading should have been allowed.
(Although I do admit operators in Scala get confusing as hell. I like one of the recent RFCs that would require every Scala operator to have an actual "word" function alias to go with it so you can tell what the hell it does).
But i assume you're ok with upcasting an int to a double. That is, unless you make the Haskell Prelude. There is a real and useful sense in which booleans are a subtype of integers and i think its not unreasonable to automatically cast between them. Can't say if it's a good idea or not though.
There is a real and useful sense in which _everything_ is an integer; see Godel numbering. There's also a real and (debatably) useful sense in mathematics in which everything is a set. Even still, we prefer to impose structure and convention because it helps us understand what's going on, by restricting the kinds of things we need to be able to expect.
Booleans are the same kind of thing. We don't normally do arithmetic on them; at most we might treat `bool` like Z-mod-2. But Z-mod-2 behaves very differently from `int`.
I'd love to hear of a case where anyone has actually computed a Goedel number.
We very often do arithmetic on booleans, the a canonical homomorphism (Iverson bracket) with 1 ~ True and 0 ~ False where && and || are multiplication and addition. But I guess you knew that.
That is not the only homomorphism. You could just as well have 0 ~ True and 1 ~ False, where && and || are addition and multiplication. Booleans don't have enough algebraic structure to nail down a unique embedding. Integers and reals don't have the same problem, because there's a unique ring homomorphism between them.
Type class instances are only “canonical” by fiat. Once you elaborate type classes into record-passing, by no means are the resulting instance types uniquely inhabited.
This is just as bad as the existence of truthy or falsy values.
You should get a type error if you try to use an int in boolean logic.
So define:
def __bool__(self):
raise TypeError("I don't like non-bool booleans")
on your classes, and you're good to go. Python isn't doing type conversion, it's doing operator overloading and letting you define how your class should work with the 'if' statement. It won't help you with the already-defined behavior of built-in and third-party classes, but you can have all your own code be unusable in boolean operations if you like.
If your language has “low level” integers that can take on exactly 2^n values, all bit patters are numbers, so there is no need to “check whether there is a number there at all”.
If, in addition, you want implicit conversion from integers to booleans, you have to pick some patterns as meaning ‘false’.
The first is fairly normal in low-level languages. So, the question is why one would want implicit conversion from integer to boolean. The main reasons I can think of are
- because assembly doesn’t have boolean.
- to keep source code shorter.
For C, I think it was a combination of both. Testing for null pointers using if(p) is nicely short. From there, given that there’s little or no difference between pointers and integers at register level, it is a short step to if(i) for integer i.
What is flags register file for then? Zero flag, carry, overflow, etc? They sure look booleans to me. Sometimes assembler routines pass booleans in carry flag.
Hmm. If you have a measurement of zero, you still have a measurement, which is more different to having no measurement at all than it is to having a measurement of 1. Especially if you are measuring centigrade!
Is there a measure at all? This is a different question than the value of the measurement. (Though "I don't know" doesn't map very well to rational numbers... maybe a float NaN could be abused).
That's why many databases allow for (the option of) types to include a NULL value that is handled specially.
When you are rolling your own data design it is a legitimate question to ask: "Will an incomplete version of this object exist?" If the answer is yes, then the design should accommodate making that distinction.
I only received a downvote. To clarify, I mean that most people know what it means to "have -1 apples" (it would mean you owe one apple.) So why should negative values be truthful, if it's a simple analogy with the real world?
This phrasing shows the error even more starkly. No, you don't owe anything if you have 0 apples. If you use this as a test, however, then you also either "don't owe" anything if you have -5 apples, or you do owe something if you have 5 apples. You simply can't use this as the test.
To put this into code directly based on the logic you say it's an analogy for:
numapples = 0;
// Do you owe anything if you have 0 apples?
if (!numapples) {
printf("I don't owe any apples.\n");
}
else {
printf("I owe some apples.\n");
}
This simply doesn't work. (Gives wrong result at 5 for example.)
The correct tests are, respectively:
numapples = 5;
// have no apples
if (numapples == 0) {
printf("I don't have or owe any apples.\n");
}
if (numapples < 0) {
printf("I owe some apples.\n");
}
if (numapples > 0) {
printf("I have some apples.\n");
}
There is another, subtler, reason for this. What is special about the value "0" here is that it's the default value - you're born without any apples, or something.
But by making someone write the test like this:
(currentapples - startingapples) == 0
you can test whether there is any offset from a different starting value. The "0 == false" version of the test completely breaks that: it applies when you're testing an offset at 0, but breaks anywhere else. In other words as an offset it's equivalent to:
don't get me wrong, I use it in code. But I'm not under the misapprehension that there is a real-world analogy. There isn't one. It's simply the definition of C/C++.
Whenever I see == 0 in an if test, I feel free to remove those 4 characters, don't get me wrong. Because it's just the definition of C. Not because I think there's any analogy with anything.
That said, which version of this code is cleaner and less likely to allow a programmer to make a logical mistake:
1.
if ((currentapples - startingapples) != 0) {
2.
if (currentapples - startingapples) {
to me, the intent of 1 is super-clear, as for the intent of 2, who knows, but of course after half of a second I can parse what its effect is, by running through the definition of C in my head. That's not great for reading and debugging programs. :)
I agree completely. This behavior is internally consistent within Ruby and the standard library and allows for some of the terseness of Ruby that I love. Things like =~ which return the position of the first regex match on a string (which could be 0 position).
> Is there a good reason, other than expectations brought from other langs, why 0 should be falsey?
Most likely this is a result of one of the mother of most bracket based languages specifically C and it's children. BCPL did not have multiple data types which I would guess was an artifact of it's time. I am not certain if this is still the case, but a language that was built in the 60's clearly had limits that are no longer valid. With no types it would be natural to define a boolean as a 0 and 1 in binary which would give you your 0 is falsey.
I was not born yet, and I expect you probably where not as well, when these pivotal decisions where made. It is still interesting to look back and see how what we do today was the result and the why of our forefathers in computer science. For example at the time I can see why Ken Thompson would make the choice of = as assignment instead of := to save bytes and use == for comparison. Assignment being a more often operator would indeed save space, but the amount of bugs it's created since then he probably would not have made that decision.
More fundamentally, you want to be able to distinguish the representation(s) of true from false as efficiently as possible, so to work on most machines the choice is either zero vs nonzero or negative vs nonnegative.
I don't really like 0 being truthy or falsy. For 'true' or 'false' flags you could just have a bitset, and everything else can have specific tests for type or value. I actually kind of half suspect that you don't need booleans or 'truthy' things at all. Or null.
Success being false is definitely an odd pattern to me. I know I’m not the only one tripped up by it (‘canWrite()’ should return true on success...except if you want to return an error code by value). This is sort of fixed with C++ ‘enum class’, but obviously this isn’t always possible to use.
To me this comment is actually good evidence for why 0 shouldn’t be truthy. The reason you gave sounds like an anti-pattern that can only exist because 0 is truthy; so a good reason to have a falsy 0 is that you couldn’t do what you said you often do. In my opinion type checking should be more explicit than you’re comment suggests.
Maybe it's an antipattern to take "if x" to mean "if x is a numeric value". But if so it's surely more of an antipattern to take it to mean "if x is a numeric value that is not zero". I think the way out of this sort of antipattern, if antipattern it is, is to get rid of the idea of numeric values being truthy or falsey at all. I think your problem is with the whole concept of truthiness.
"is" isn't equivalent to equality in Python. Is specifically checks the memory address, not equality. Equality is checked with "==" like in any other language. The author probably saw the is operator used somewhere and didn't know enough Python and figured that since && and || are reserved for bitwise operations whereas "and" and "or" are used for logical operations, "is" must also be the Python version of "==".
Java's == is not used for equality for objects either, so it's a valid comparison because Java's behaviour is equally unintuitive here. It's the same behaviour as is for objects.
Java's behavior feels like an almost deliberate trap, though. I have previously lost hours to bugs resulting from a refactoring that changed a value's type from int to Integer, and the resulting change in equality semantics.
That seems like such an anti-feature. I'd want the compiler to issue a warning for it by default and the IDE to ship with 'warnings are errors' by default.
Instead, we have some $$$$ static analysis tool that nags me endlessly about using Optional<T> private fields, but lets using the == operator for non-primitives sail past without comment.
I don't think the author meant to imply that "is" is equivalent to equality. I think the author was specifically trying to check the references to see where python stops coalescing integers.
I guess, but then it's also kind of uninteresting. Lists in Python are an array of pointers. That Python implements assignment differently is kind of an odd detail, but altering the value of one of the variables doesn't alter the value of the other. It's just sort of an under-the-hood implementation detail visible only through Python's introspection tools, not something that actually affects code. I tried it myself:
The point is that is is making those implementation details visible. That is absolutely going to affect code relying on those details. It won't affect good code, of course, but everyone writes stupid code in a while, and if it appears to work, nobody will fix it.
I am starting to hate languages that are not super picky and precise. We are working with C#, PHP and JavaScript and between them it's almost Impossible to remember what will evaluate as what. I would be perfectly fine if the only input to an if was true or false, no number, no strings.
Same here. I’ve used C for ages and now I’ve been doing a lot of Swift, where if statements only operate on Bool values. I find it much better to be explicit about any condition that isn’t literally true or false. The common style of accepting all types and defining a set of “falsey” values just encourages pointless shortcuts.
I mostly use Asm and C, and I have the exact opposite opinion: I hate languages like that. It makes simple problems like "determine if more than 1 of 3 integers are greater than 4" require ridiculously verbose solutions.
How can it be ridiculously verbose? Converting an arbitrary expression into C’s notion of true or false just requires adding != 0 or != nil or similar.
I'll make a suggestion that's more verbose but maybe(?) more elegant (in the sense I'd argue it's more quickly evident what's being done and might conditionally improve performance):
if (a > 4) {
return b > 4 || c > 4
} else {
return b > 4 && c > 4
}
My argument is that the boolean operators make it more evident immediately that the return value is a boolean value (well, a 1 or 0 in C). Also this doesn't explicitly check the case of all the checks evaluating to true, but it doesn't need to because in that event then the if condition evaluates to true and the return value is true, which is the correct return value in that situation.
You could use the ternary operator in place of the if syntax to reduce the verbosity, but I find the smaller statements easier to read quickly.
Additionally, I think(?) this code would have an ever-so-slight performance advantage in some situations since in the event a > 4 and b > 4 evaluate to true, then c > 4 doesn't get evaluated. Same if a > 4 but b < 4.
Not with a computer I can easily run C on at the moment to check these claims, but I welcome input on the elegance/performance/readability comparisons.
You might like Haskell. The only possible conditional is a boolean and in general it's quite picky and precise about everything (with a few notable exceptions like partial functions).
The item in the list supplied for index starting at 1 shouldn't be there.
There are valid reasons for using 1 instead of 0 for the first element. It all hinges on whether the address is being considered or the first element is being considered.
One could consider languages that use 0 as the alternative referencing for the end of some value that can be indexed and -1 as the last item of that value.
Is there a good reason, other than expectations brought from other langs, why 0 should be falsey?