David Vallner
8/26/2006 3:16:00 PM
Pavel Smerk wrote:
> David Vallner wrote:
>> Pavel Smerk wrote:
>>
>>> OMG!
>>>
>>> Why the and and or operators have the same priority? Unlike && and ||
>>> and also unlike the most of, or maybe all, other languages and
>>> conventions?
>>>
>>> (Yes, long time spent on that now, who would expect such a curiosity...)
>>>
>>> Thanks for explanation, if there is any,
>>>
>>> P.
>>>
>>
>> <rant>
>> Just. Use. Parentheses. Even in programming languages where the rules
>> are clear. Explicit >> Implicit.
>> </rant>
>
> More parentheses, less readability. E.g. the natural language is quite
> well understandable without the parentheses --- and (((I'm) sure),
> (((it's) (better understandable)) (than (it (((would be) understandable)
> (with them)))))). May be its operator precedence is better designed than
> the ruby's one? (Although it can be hardly believable that something
> could be even better than ruby. ;-)
>
And for Christmas, I want a pony or a doggy and rollerskates and a bike
or a computer and an action figure and a toy car or a goldfish or new
shoes and a TV.
So...
Perfectly understandable? Only if people naturally follow boolean
algebra rules when talking. (Riiight.) Of course, the above sentence is
particularly convoluted (making it no more a contrived example than
yours I'd say though), that's why it's pretty much impossible to
determine what it's supposed to say. Which is my point: if you want
programming language code as readable as natural language, just using
words instead of symbols doesn't cut it - you should phrase your
expressions clearly nonetheless. Like, oh, without long tangles of ands
and ors.
For what it's worth though, since most programmers DO expect
mathemathical rules to hold in programming languages, for the sake of
consistency, I agree that the and should bind more tightly than or now
that that's been brought up. I just don't really consider it critical
since I believe you should never mix those in a single expression at all
- boolean expressions are for me much easier to visually parse as "one
must be true" or "all must be true" when you don't have nested anonymous
complex terms involved. Those are a good candidate for extraction into a
local variable or a separate predicate method.
David Vallner