Live data from Hacker News

Why 1 && 2 == 2

blog.chewxy.com

21–30 of 58 posts

Re: Why 1 && 2 == 2

#21
post #11

Earlier quoted context omitted.

Just for my curiosity's sake, would you mind posting the code you tried that segfaulted?

Yeah I'm dying to see the original C code but it isn't on the page anywhere, AFAICT. From the article, about the C version: "Mine hadn't worked, which I suspect is some sort of compiler issue." Yeah I'm going to go out on a limb and proclaim that there's no way this was due to a compiler "issue" in gcc. Not that gcc is perfect, but there's no way it is barfing on one of these handful of line programs that does nothin…

My thoughts too.

Re: Why 1 && 2 == 2

#22

For Python, a common idiom is to do this: condition and truecase or falsecase See "Boolean operations" and "Conditional expressions": http://docs.python.org/3/reference/expressions.html#boolean-...

ah! I've been trying to write Python lately (I'm more of a Rubyist) and the internet suggested:

truecase if condition else falsecase

which is so inside-out that it hurts.

It didn't occur to me to use the boolean style - I guess I think of that as a perl idiom, and assumed that it would get sneered at in py-land

Re: Why 1 && 2 == 2

#23
Once you understand short-circuit evaluation, it opens up certain coding tricks.

The line "[operation] or [error condition]" will attempt the operation on the left. If it succeeds, the program continues on the next line, ignoring the part about the error condition. If it fails, the error condition will execute instead. This might be something like "open file or die".

Likewise, "[operation] and [success condition]" will attempt the operation on the left, and if it succeeds, perform the operation on the right. This might be something like "read input and process it", which will perform the (possibly expensive) processing step only when input is received.

Code written in this style is sometimes, but not always, faster to execute. It's also sometimes, but not always, clearer.

See also http://en.wikipedia.org/wiki/Short-circuit_evaluation

Re: Why 1 && 2 == 2

#24
Common Lisp treats any non-nil value as "true," so the behavior is not bad for the "and" macro (yes, it is a macro). Additionally, the standard says that "and" should evaluate to nil if any argument evaluates to nil, or to its last argument otherwise:

http://www.lispworks.com/documentation/HyperSpec/Body/m_and....

Re: Why 1 && 2 == 2

#25

Once you understand short-circuit evaluation, it opens up certain coding tricks. The line "[operation] or [error condition]" will attempt the operation on the left. If it succeeds, the program continues on the next line, ignoring the part about the error condition. If it fails, the error condition will execute instead. This might be something like "open file or die". Likewise, "[operation] and [success condition]" wi…

This is commonly seen in Perl and PHP with stuff like

    launchMissiles() or die('failure');

Re: Why 1 && 2 == 2

#26
post #11

Earlier quoted context omitted.

Just for my curiosity's sake, would you mind posting the code you tried that segfaulted?

Yeah I'm dying to see the original C code but it isn't on the page anywhere, AFAICT. From the article, about the C version: "Mine hadn't worked, which I suspect is some sort of compiler issue." Yeah I'm going to go out on a limb and proclaim that there's no way this was due to a compiler "issue" in gcc. Not that gcc is perfect, but there's no way it is barfing on one of these handful of line programs that does nothin…

Nope. The answer is still I suck at C.

Parts of the blog post was written late last night (about 3 am), and parts of it was written on my commute to work. I tried to rewrite what I wrote last night and tried to compile it on my work computer, and all I got were warnings.

So... can't recreate. Sorry

Re: Why 1 && 2 == 2

#28

Thank god he didn't try php. echo 2 && 1; // 1 echo 1 && 2; // 1 echo 2 || 1; // 1 echo 1 || 2; // 1 echo 2 ?: 1; // 2 In php ?: is javascript's || Unfortunately there is no && that works correctly.

Incidentally, this is identical to the result in GNU C.

Re: Why 1 && 2 == 2

#29
I think it's a sign that I've been programming (predominantly in ruby) too long when I didn't think twice about why 1 && 2 == 2.

Re: Why 1 && 2 == 2

#30
post #22

For Python, a common idiom is to do this: condition and truecase or falsecase See "Boolean operations" and "Conditional expressions": http://docs.python.org/3/reference/expressions.html#boolean-...

ah! I've been trying to write Python lately (I'm more of a Rubyist) and the internet suggested: truecase if condition else falsecase which is so inside-out that it hurts. It didn't occur to me to use the boolean style - I guess I think of that as a perl idiom, and assumed that it would get sneered at in py-land

It was mostly used before the creation of the ternary operator in Python 2.5.
Post reply on HN