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."
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.
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!
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'.
Jason
···
On Sat, Aug 23, 2008 at 1:31 PM, Dave Bass <davebass@musician.org> wrote:
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.
--
Posted via http://www.ruby-forum.com/\.
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".
David
···
On Sun, 24 Aug 2008, Dave Bass wrote:
--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL
See http://www.rubypal.com for details and updates!
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, 2008-08-24 at 02:31 +0900, Dave Bass wrote:
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.
--
M. Edward (Ed) Borasky
ruby-perspectives.blogspot.com
"A mathematician is a machine for turning coffee into theorems." --
Alfréd Rényi via Paul Erdős
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.
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.
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.
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.
···
On Sun, Aug 24, 2008 at 1:26 PM, matu <m@t.u> wrote:
Dave Bass wrote:
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.
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!
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.
- Charlie
···
On Sun, 2008-08-24 at 02:31 +0900, Dave Bass wrote:
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!
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
David
···
On Sun, 24 Aug 2008, M. Edward (Ed) Borasky wrote:
On Sun, 2008-08-24 at 02:31 +0900, Dave Bass wrote:
--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL
See http://www.rubypal.com for details and updates!
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.
···
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!
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.
And he covered that in his examples. He was using == false as a shortcut to say "conditionally false".
* 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.
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.
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.
···
On Sun, Aug 24, 2008 at 3:30 PM, Phlip <phlip2005@gmail.com> wrote:
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
For the second time so far: His statement is jargon, and is not to be taken
literally. His code sample showed what he meant!
