Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dennis Ritchie on the priorities of && || vs. == etc. (1982)

lysator.liu.se

Post reply on HN
Print view View original

101–110 of 178 posts

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#101

Post by Terr_ »

User23 wrote: post #70
Sohcahtoa82 wrote: post #2

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

You’re in good company[1]: Do not introduce priority rules that destroy symmetry. I remember how much more pleasant the predicate calculus became to work with after we had decided to give con- and disjunction the same binding power and thus to consider p ∧ q ∨ r an ill-formed formula. [1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...

> We don’t want to baffle or puzzle our readers, in particular it should be clear what has to be done to check our argument and it should be possible to do so without pencil and paper. This dictates small, explicit steps.

I feel this justifies why I sometimes write code with lots of temporary variables on their own lines: It's a way to break down the problem, to name each thing (especially when it's not a simple method-call to a correctly-named method) and it also makes it easier to verify the behavior with the average line-by-line debugger or line-by-line debugging easier.

In many cases, such temporary local variables have no negative performance impact, being optimized away.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#102

Post by saberience »

thomasahle wrote: post #75
sublinear wrote: post #54

Earlier quoted context omitted.

Explicit is better than implicit. I think the real problem is not breaking up complicated expressions. If it's more than just a few pairs of parentheses making it hard to read there's something more wrong there.

I think most people agree "a*x**b + c" is more clear than "(a*(x**b))+c". Or "a+b+c+d" is more clear than "a+(b+(c+d))". Why are we happy to avoid parentheses for these operations but not for && and ||? Probably because we are all really used to the precedences for + and *. So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators.

I think the opposite, I think most people would prefer the version with parentheses, including myself, also, in 20 years experience all companies I’ve worked for would prefer the second expression.

The first expression looks messy and confusing, the second is completely clear in how it will work.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#103

Post by zzo38computer »

Sohcahtoa82 wrote: post #2

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

I also do (it also makes it more clearly, in my opinion), as well as with the bitwise operators & and | but sometimes with the bitwise operators the code is written in such a way that the precedence doesn't matter anyways and so I will not need to add parentheses anyways.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#105

Post by elromulous »

Denvercoder9 wrote: post #53
laxd wrote: post #51

Earlier quoted context omitted.

Lower than either, so you can do logical (or arithmetical) expressions on both sides of ==. Has nothing to do with nature, it's all about pragmatic decisions on how we want it.

Wrong. In C and C++, == has a higher precedence than && and ||, so `A && B == C && D` parses as `A && (B == C) && D`.

== is really just a logical xor anyway.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#106

Post by _zagj »

neilv wrote: post #100
_zagj wrote: post #81

Earlier quoted context omitted.

> except in broken languages, of which the only notable one is shell All binary messages in Smalltalk (messages with selectors consisting of punctuation, like !@+-, including punctuation sequences like "+-&|", if you want) have the same precedence, and the keyword variants (which short-circuit, using block arguments) and: and or: also have the same precedence (one level lower than the binary/punctuation messages), bu…

> Smalltalk [...] what r5rs Scheme should have been. I'm a fan of both languages, but R5RS Scheme was to be an algorithmic language, and Smalltalk is a particular flavor of OO language (class-instance, single dispatch). Would you say that doing conditionals and Boolean expressions with Smalltalk's object semantics and `ifTrue:ifFalse:` and mix of `and:` and `&` etc. is cleaner than Scheme's `if`, `and`, etc. syntax?…

By "should have been" I meant striking the balance of simplicity, power, and ease of learning that Smalltalk does. R5RS is simple and powerful (even more powerful due to macros), but not really usable, since it doesn't ship with something like Smalltalk's object model out-of-the box that streamlines creating ADTs and code reuse. Instead they give you the rudiments (functions, closures) and leave everything else up to you.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#107

Post by userbinator »

thomasahle wrote: post #75
sublinear wrote: post #54

Earlier quoted context omitted.

Explicit is better than implicit. I think the real problem is not breaking up complicated expressions. If it's more than just a few pairs of parentheses making it hard to read there's something more wrong there.

I think most people agree "a*x**b + c" is more clear than "(a*(x**b))+c". Or "a+b+c+d" is more clear than "a+(b+(c+d))". Why are we happy to avoid parentheses for these operations but not for && and ||? Probably because we are all really used to the precedences for + and *. So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators.

Parentheses need to be matched. That adds cognitive overhead. It's especially frustrating when you find the closing parenthesis and then realise it wasn't even necessary.

IMHO it's on a similar level as "== true" "== false" and variations thereof --- absolutely redundant and unnecessary, and shows a lack of knowledge. The same "explicit is better than implicit" mantra is often repeated to justify the latter, but if you think

    if(x == true)
is somehow more "explicit", then surely

    if((x == true) == true)
is even better?

So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators

If someone is not familiar then they should be encouraged to learn and level up, rather than pulling down everyone else.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#108

Post by dietrichepp »

o11c wrote: post #8
Sohcahtoa82 wrote: post #2

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

Convert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

My problem here is that I distinguish between multiplication and addition by seeing which one distributes over the other.

  a * (x + y) = (a * x) + (a * y)
However, the reverse doesn’t work…

  a + (x * y) =? (a + x) * (a + y)
Why is this a problem?

  a ∧ (x ∨ y) = (a ∧ x) ∨ (a ∧ y)
  a ∨ (x ∧ y) = (a ∨ x) ∧ (a ∨ y)
Both are true. So, who are we to say that one corresponds to multiplication, and the other corresponds to addition? The two operations are too similar to each other.

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#109

Post by torstenvl »

Sohcahtoa82 wrote: post #2

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

Do you know the priority in this?

[ -e "${target}" ] && echo "Getting information about ${target}" && stat "${target}" || echo "Failed to stat file."

EDIT: What about the || die("...") pattern in Perl?

Or the fact that the glyphs in || are visually lower than the glyphs in &&?

Or that "and" comes before "or" in the expression "and/or"?

Re: Dennis Ritchie on the priorities of && || vs. == etc. (1982)

#110

Post by pavlov »

torstenvl wrote: post #109
Sohcahtoa82 wrote: post #2

I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.

Do you know the priority in this? [ -e "${target}" ] && echo "Getting information about ${target}" && stat "${target}" || echo "Failed to stat file." EDIT: What about the || die("...") pattern in Perl? Or the fact that the glyphs in || are visually lower than the glyphs in &&? Or that "and" comes before "or" in the expression "and/or"?

Shell scripting sucks, but that’s hardly news.

If I really have to touch a bash script, I just assume nothing works like I might expect from proper programming languages despite any surface similarity, and google every construct with sweat drops dripping down my face. ChatGPT has made the process somewhat more tolerable.

Post reply on HN