7 ms·
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
by boffinism 9y ago
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?
- Shoothe 9y agoNope. JS is notoriously bad at this matter having several falsy values. At least Ruby keeps it at minimum, only false and nil.
- na85 9y agoWhy not use an isNumeric() to check if there is a number?
- aetherson 9y agoI hate truthy- and falsy-ness in general. It just seems like it's ripe for messing up expectations. Why not just get an actual boolean?
- CalChris 9y agoBut I think we can agree that truth should be truth and that false should be false and that we shouldn't be able to assign false to truth.
- blattimwind 9y agoIs alternate truth ternary?
- djsumdog 9y agoI 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).
- Y_Y 9y agoBut 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.
- Twisol 9y agoThere 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`.
- Y_Y 9y agoI'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.
- yorwba 9y agoThat 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.
- rimliu 9y agoThat’s how Swift does it. It may annoy you now and then but a few seconds later you are glad being forced to be explocit.
- stctgion 9y agoIf you don't allow uninitialised variables
- krapp 9y agoI 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. I'm probably wrong though.
- aaachilless 9y agoTo 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.
- boffinism 9y agoMaybe 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.
- traviscj 9y agoMore simple semantics are easier to understand. Ergo we should make the semantics as simple as possible. More complicated semantics save more words. Ergo we should make the semantics as complicated as possible. (This specific example is probably a false dichotomy--"the concept of truthiness" might be neither as simple nor as complicated as possible.)
- sillysaurus3 9y agoWell, if you're talking philosophy, then no. There's no reason. It's a design decision, so it should be informed by the audience of the language.
- userbinator 9y agoIs there a good reason, other than expectations brought from other langs, why 0 should be falsey? Zero is an absence, and it has a good analogy in the real world: If you have 0 apples, you do not have any apples.
- logicallee 9y ago>good analogy in the real world: If you have 0 apples, you do not have any apples. unless I owe some apples - in which case, by your "real-world" test, I do have some?
- logicallee 9y agoI 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?
- userbinator 9y agoSo why should negative values be truthful, if it's a simple analogy with the real world? Do you owe anything if you have 0 apples?
- logicallee 9y ago>Do you owe anything if you have 0 apples? 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: ( currentapples == zeroapples ) && (zeroapples == 0) 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. :)
- Someone 9y agoIf 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.
- vardump 9y ago> because assembly doesn’t have boolean. 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.
- normaljoe 9y ago> 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.
- kps 9y agoMore 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.
- mberning 9y agoI 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).
- abecedarius 9y ago0 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. Still I prefer a distinct Boolean type, too.
- aisofteng 9y agoIf a function returns 0 when it succeeds and some nonzero value as an error code when it fails, then you can write if(myfunc(...)) { ...
- a_t48 9y agoThis works fine until you have some other function that returns 0 on failure.
- aisofteng 9y agoThis has never been a problem for me and I've never heard of it being a problem for anyone else.
- a_t48 9y agoSuccess 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.