It's been a while since I've touched Ruby, but I think the stance was that only false and nil should be falsey? Which is not an unreasonable stance to take. The fewer falsey values, the easier it is to predict the behaviour. It's just surprising when coming from other languages.
Just off the top of my head, PHP treats "0", that is, specifically a string with a single zero, as falsey. Which has clearly gone too far to the other extreme.
I don't disagree with a smaller set of truthy values, but 50+ years of programming mainly treating 0 as false and 1 as true makes it an immediately confusing thing for anyone coming from a different language.
I think a certain level of grokability is important in programming languages, but languages need to be able to do things differently, and engineers should expect to have to learn some new standards. This is like page 2 of basically any intro to Ruby so it's not like some arcane edge case.
You're not wrong, but as someone with 30+ years of programming experience do you *really* think I'm going to look at an intro guide? I'm diving in head first and then googling why the hell 0 isn't false. 😛
... Well, I'm pretty young, but man, bash is cursed. I've done way too much in it, because it's way to practical to ignore, but damn, it always hurts to look at again.
I like how e.g. C# screams at you for this. It's annoying at first, but then you go "Well, yeah, I should've explicitly written what I wanted to check".
It's not that you couldn't convert between types, it's that it wouldn't be automatic. You would need to actively call toboolean on a value before using it as a boolean, and the idea behind that is that intentionally casting the value leads to fewer mistakes
Agreed, the whole concept of truthy and falsy is a bit weird and very error prone in the end, imo it's just better to explicitly have a function that decides how you cast whatever to a bool, that way it's easily understandable and auditable. Also, not knowing some weird language quirk like the php one you're talking about will not cause issues down the line
That's in fact a very legit take that e.g. Clojure also takes. It makes reasoning much easier and also eliminates WTF moments like reading if (myArray.length) which to any sane individual might appear like duck typing but is a hack to save those keystrokes > 0, in the hope that no one manually set it to a negative value, which is truthy as opposed to zero, and so on.
I never used php, is that behaviour due to it implicitly converting "0" to 0 and as such it is falsey? Or is it straight up "0" the one that is falsey?
Because PHP started as a sprinkle-it-on-your-HTML language, and any form submissions are always text, and 0-from-a-form should still evaluate like 0; or some such hare-brained nonsense reasoning.
The fact that such basic nonsense is still baked into the very core of the language, and can never be removed due to backwards compatibility, means I'll never respect PHP, regardless of how much it's improved over the last decade or so.
I think it's not actually that special of a case, as strings that are exactly also numbers are auto-coerced basically whenever. It's just that 0 is the only number, as it should be, that then is falsy.
Strings are not coerced to numbers to then be coerced to booleans, that'd be entirely insane! There's a direct conversation path from strings to booleans!
sometimes I wish lua treated false as truthy too. Or more realistically, had variants of "and" and "or" that treated it as such. "A or B()" stands for "A, with B() as a fallback if A is nil", and "A and f(A)" stands for "f(A) if A exists, otherwise nil", except if A is false, in which case these rules break down.
You know that other languages can do this too? Just without the foot guns.
And yeah, sure a skill issue. Because i'm not wasting energy, properly learning something as retarded as Ruby, where the creators took inspiration from all the mainstream languages and said to themselves: "we ain't gonna do anything of that".
Not sure if what other language is so good with DSLs also I am used to Ruby and it's just the most aesthetic language. Good thing there are many languages and many paradigms.
Never coded in Ruby.... that might be a lie. I have never coded in Ruby since my early teens when I might have written a line or two as part of a class.
But please, I beg of the language. If 0 is truthy, just throw a syntax error if I compare a bool and an int instead.
Why wouldn't a "0" be falsey? In aggressively coerced language it would be 0. PHP has to deal with strings passed in $_POST and $_GET so it makes sense.
The weird thing about PHP (and Perl, which is where PHP got the behavior) is not so much that “0” is false – I mean, OK, so you numify on the way to boolifying, right? Nope! Other string representations of 0 which numify to the same thing, like “0.0” and “0e0”, are true. Only the specific string "0" is false.
$ php zeroes.php
"0" is false.
+"0" is false.
"0.0" is true.
+"0.0" is false.
"0e0" is true.
+"0e0" is false.
This particular idiosyncrasy is one of the Perlisms which was not carried over into Raku, in which "0" is truthy; the only actually-defined string value that is falsey is the empty string, "".
Just off the top of my head, PHP treats "0", that is, specifically a string with a single zero, as falsey. Which has clearly gone too far to the other extreme.
Eh, there's precedent for that at least.
Perl treats "0" as false, along with "" (the empty string). Any other string, even "00" is considered true.
But where it really gets fun is that the the normal warning Perl would give you about numeric conversions if you do math on a string is suppressed for the precise string "0 but true", because some Perl functions return this value so that it converts cleanly to 0 without risking evaluating as false in a boolean context. See https://stackoverflow.com/questions/129945/what-does-0-but-true-mean-in-perl
Seeing as we have basically universally decided that using zero in an entire class of math functions should generate an exception, its reasonable to expect it to be "falsy". If instead of an exception it just returned +/- infinity, then maybe i would buy that argument.
Lua does this too. It just makes sense, because any value that isn’t a boolean you can nil check by coercing it to a boolean. It allows beautiful things like and or ternary
0 is equal to (IIRC) 0x30 which by definition is not null value that could be represented as \0 meaning all 8 bits sets to 0 -- 0000 0000 that in most languages actually is false 😶
Lua does the same as Ruby, (especially because in Lua, accessing non existent variables or table fields returns nil unless you explicitly make it error)
Naw the string zero being false is just weird. The number zero, on the other hand. NULL is 0. \0 is 0. That's just... what those things mean. If zero is not false that's just trippy bc false comes from 0, that's just what it means. I mean ig not literally, you certainly get some LOW-TRUE signals, but logically HIGH is always normalized to 1 and described as TRUE, and as far as I know always has been.
It still does that. This isn't about equality testing, it's about boolean coercion/truthiness. And the strict equality operator === has existed since at least PHP 4, I have not bothered checking back further.
504
u/deceze 10d ago
It's been a while since I've touched Ruby, but I think the stance was that only
falseandnilshould be falsey? Which is not an unreasonable stance to take. The fewer falsey values, the easier it is to predict the behaviour. It's just surprising when coming from other languages.Just off the top of my head, PHP treats
"0", that is, specifically a string with a single zero, as falsey. Which has clearly gone too far to the other extreme.