One of the first “gotchas” here coming from another language is 0 is not
like
‘true’. This Daily WTF (which I think someone just posted here)
illustrates the
problem which Ruby solves:
“Rather than check the difference between 0 and FALSE (or use a more
appropriate
function), the original developer just dropped the first letter of each
crawler
name so that strpos doesn’t return 0.”
$spider_footprint = array('ooglebot', 'rawler', 'pider', 'ulliver',
'arvest', 'ahoo! Slurp');
foreach($spider_footprint as $spider_name)
{
if (strpos($agent, $spider_name))
{
$is_spider = 1;
…
The problem is not that the programmer did not want to add FALSE != .
The
problem is that language treats 0 as false, when 0 positively means we
have a
good value with a 0 inside it.
0 as FALSE is a legacy of languages that could not distinguish 0 and
NULL.
So the Ruby version would work like:
if agent.index('googlebot')
So, once again, Ruby gives us the right defaults, precedents, and
operations
that do much more, with much less code.
It’s a perfectly fine feature and makes perfect sense if you
understand Ruby’s object model. 0 is not nothing, it’s Fixnum(0). Thus
it’s an object, and not anything that can be differentiated from, say
2, 5 or “some string”. Of course nil is NilClass and false is
FalseClass, which are also objects, but there needs to be something
that allows for if(false) checks, so those two classes are the special
cases. When taken as in context of Ruby as a whole, this of course
makes sense, as nil is effectively our nothing (like NULL / 0 in C and
C++) and FalseClass is our actual ‘false’.
But unfortunately Ruby regards both false and nil as not-true. For some
reason, this is touted as a feature.
False and nil are two quite different concepts and should not be
conflated.
They’re not conflated, though. The two objects false and nil have in
common that they present as false, in the boolean sense, so that “if
false” and “if nil” both branch away. I think that’s reasonable, since
otherwise you’d have to do a lot of “if (expr).nil? ||! expr” and
stuff like that. But they’re still different objects, and the concepts
of falsehood and nilness are handled separately but converge at the
point of boolean value. The same is true of, say, the objects true and
“string”.
It all comes down to the difference between being an object and having
a boolean “persona”.
But unfortunately Ruby regards both false and nil as not-true. For some
reason, this is touted as a feature.
False and nil are two quite different concepts and should not be
conflated.
So the Ruby version would work like:
if agent.index('googlebot')
So, once again, Ruby gives us the right defaults, precedents, and
operations
that do much more, with much less code.
If you need false==, to self-document with more code, go for it. Given
the
choice of forcing you to conflate 0, FALSE, and NULL, and only
conflating
two of them, Ruby picked the right two, for nearly all situations. If
you
want Pascal or Ada, you know where to get them!
So I don’t have a problem with 0 not being false, but I do have a
problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
0, nil is nil, true is true and false is false and that is that!
I tend to look at these things not from at the level of pedantic
consistency-mongering but in terms of what would be lost if the concept
were changed.
a ||= x would no longer work, since unassigned a (nil) would not
evaluate to false causing x to be assigned.
@a ||= x would no longer work
a[n] ||= x would no longer work
a.b ||= x would no longer work
“nil” being considered a boolean false seems absolutely natural to me,
and it makes possible a large number of concepts in Ruby we’d really
miss.
But unfortunately Ruby regards both false and nil as not-true. For some
reason, this is touted as a feature.
False and nil are two quite different concepts and should not be
conflated.
Exactly! To make matters worse, Lisp “traditionally” treated nil as
false, but Scheme has “true”, “false” and “nil” and nil is treated as
true in Scheme.
So I don’t have a problem with 0 not being false, but I do have a
problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
0, nil is nil, true is true and false is false and that is that!
On Sun, 24 Aug 2008, M. Edward (Ed) Borasky wrote:
So I don’t have a problem with 0 not being false, but I do have a
problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
0, nil is nil, true is true and false is false and that is that!
I understand what you’re saying but I have a real, non-rhetorical
question: In practical terms, what do you think should be done about
such a situation? It seems to me that there are two possibilities:
either computer languages really do things differently, including
things like this (not just stylistic and/or cosmetic things), or they
don’t and then they all become the same.
I can’t think of a third possibility, and of course I like the first
better than the second
a ||= x would no longer work, since unassigned a (nil) would not
evaluate to false causing x to be assigned.
@a ||= x would no longer work
a[n] ||= x would no longer work
a.b ||= x would no longer work
Exactly! a positively-written program should propagate value-objects,
and
truths, as its booleans express. If you don’t like that, then your code
should
be more positive. Excess examples of ‘if nil == q’ or ‘if false == q’
are a sign
your program indulges in negativity.
So once again, a default Ruby behavior leads to better code style.
But unfortunately Ruby regards both false and nil as not-true. For some
reason, this is touted as a feature.
False and nil are two quite different concepts and should not be
conflated.
They aren’t conflated. nil != false in ruby, but nil and false have the
same conditional value. Both are conditionally false. In my experience
this has been the right call by matz all the way.
But unfortunately Ruby regards both false and nil as not-true. For some
reason, this is touted as a feature.
False and nil are two quite different concepts and should not be
conflated.
I’ve found that treating both nil and false as false to be the correct
behavior for most of my code. I’ve rarely written code where I don’t
want nil to be treated as false. Furthermore, in by far most of the use
cases, I don’t want to treat 0 as false.
In other languages, such as Perl, I end up having to write ‘if
(!defined($foo) || $foo eq “0”)’ all the time. So I like Ruby’s
behavior. Treating both nil and false as false covers most of the use
cases.
On Aug 23, 2008, at 8:35 PM, M. Edward (Ed) Borasky wrote:
Exactly! To make matters worse, Lisp “traditionally” treated nil as
false, but Scheme has “true”, “false” and “nil” and nil is treated as
true in Scheme.
So I don’t have a problem with 0 not being false, but I do have a
problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
0, nil is nil, true is true and false is false and that is that!
Back in my Common Lisp days, some Lisper (George Carrette, I think)
wrote about a dream he’d had. In it, he’d just written a fairly simple
piece of Lisp code when he realized Scheme’s strictness was right. The
rest of the post was of the form:
… and then I realized that Scheme was right about X and my code
had been taking advantage of Lisp’s sloppiness. So I fixed that…
The punch line was that every “fix” made the code longer and more
complicated. It was brilliantly done, and I’m sad I’ve never been able
to find it.
One of the simplifications/complexifications was separating nil and
false.
False and nil are two quite different concepts and should not be
conflated.
I agree with you. I am also used to this. nil should never == true, and
neither be == false. Every comparison with nil should just fail.
Well, I suggest you actually try the expression ‘nil == false’ in irb.
I think you’ll be happy to see that it is false. Nil in ruby does NOT
equal false.
As in my earlier post, it only is conditionally false, which is a whole
different beast.
False and nil are two quite different concepts and should not be
conflated.
I agree with you. I am also used to this. nil should never == true, and
neither be == false. Every comparison with nil should just fail.
Code style should prefer the if condition to pass in positive and
happy-path
situations. Further, the condition should also be stated positively.
You are asking to write extra code - if nil != my_object - for all of
your
positive situations. Then, “nil not equal” is a double negative - nil
and not.
However, Ruby is not stopping you from writing programmer-hostile code
everywhere. Go ahead and write the extra ‘nil !=’ if you must!
But I actually like rubys behaviour as well: I somehow think it’s logically
wrong, but practical.
Sorry! (-:
Always remember anyone can write code that a compiler can read. It’s a
much
bigger challenge to write code a colleague can understand.
False and nil are two quite different concepts and should not be
conflated.
I agree with you. I am also used to this. nil should never == true, and
neither be == false. Every comparison with nil should just fail.
Every comparison with nil (except with itself) does fail.
“unless foo” is not a comparison of foo with false, it is exactly
equivalent to “if not foo”.
You seem to be recommending an SQL-style 3-value logic which is
arguably useful in the context of SQL (though arguing that is a good
way to start a fight among different factions of database idealists),
but would, I think, have been a very bad choice for Ruby.
Ruby instead uses a two valued logic in which every expression must be
true or false in a boolean context. Given that, nil being false is the
only sensible answer. If you had to have it any other way, the only
even minimally acceptable way I can conceive would be nil being unacceptable in a boolean context (such that it would raise an
exception if used in such a context), so you’d have to either do
exception trapping or explicitly test for nils. While it would
invalidate a lot of compact ruby idioms, you could argue that it would
be cleaner in some respects, and it avoids the three-value logic
problems.
For the second time so far: His statement is jargon, and is not to be taken
literally. His code sample showed what he meant!
It wasn’t “jargon”, it was simply imprecise. But that’s not the issue;
his code sample showed he wanted an SQL-style three-valued logic where
NULLs (nils) propagate, which is what I addressed in the message you
responded to… If you read beyond the first two sentences, (even
through the portion you quoted of the third) you would have realized
that. You are doing the same thing (reading one piece of a message
without paying attention to the rest and criticizing based on that in
isolation) that you seem to be upset at others doing.
