Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

66%
+2 −0
Q&A Understanding "logical OR" and "logical AND" in programming languages

The explanation is that human languages are fundamentally confusing on this, but, because humans tend to be somewhat blind to complexities in systems that they've literally been the only thing they...

posted 20d ago by r.zwitserloot‭

Answer
#1: Initial revision by user avatar r.zwitserloot‭ · 2024-11-28T03:49:47Z (20 days ago)
The explanation is that human languages are fundamentally confusing on this, but, because humans tend to be somewhat blind to complexities in systems that they've literally been the only thing they've known since _before_ they have memory (you tend to learn to speak well before persists-into-adulthood memories). So they _think_ and+or is less complex than it is.

Some trivial jokes that highlight this:

-----

Jane asks Joe to go to the store to buy a loaf of bread. Oh, and if they have eggs, buy 10.

Joe returns with 10 loaves of bread. Jane, exasperated, asks Joe what the heck he thinks he's doing. Joe answer: "... they had eggs".

-----

Alex asks Sasha if she wants her cake with whipped cream or without whipped cream.

Sasha says: "Yes".

-----

More generally, the principle at work is that you need parentheses in order to determine order of precedence when you infix your ands and ors. Here's a simple truth table:

A or B and C

can mean different things depending on how you resolve it (how you determine the precedence there). It can mean:

* A or (B and C)
* (A or B) and C

For example:

If it rains or the sprinkler system is on, and the swimming pool isn't covered, the water level inside it will be raised. (this is `(A OR B) and C` where A is rain, B is sprinkler, C is pool cover).

if it rains or I'm standing over the sprinkler and the sprinkler is on, I will get wet. (this is `A or (B and C)` where A is rain, B is standing over the sprinkler, C is the sprinkler is on.

So why isn't this confusing to you?

Because of context. You are visualizing the situation. __Linguistically there is no difference here__. It is not possible to tell. If I actually meant this hard to imagine bizarre scenario, where you get wet only if:

* It is raining or you are standing over the sprinkler.
* AND, regardless, the sprinkler must be on.

(i.e. `(A or B) and C`), then I can say the exact same sentence and it can be interpreted that way equally validly.

The reason you don't interpret it that was is because you're not an idiot, and you have an imagination: You are seeing the sprinkler, standing outside, in the rain, and so on. You know which of the two _linguistically_ equally likely explanations is the obvious intent of the speaker. But this requires vast amounts of context, and, __is ambiguous__ - context cannot always make clear which one is clearly intended; ambiguity is generally hated in programming languages for fairly obvious reasons.

So, in programming languages, parentheses are used, and those new to coding find it difficult. Because __it is difficult__ and that 'applying the context to figure out what was intended' is something they've been doing since they were 3 years old, so it's difficult to realize you're even doing that.

There are exotic solutions of course. such as using postfix syntax. This:

* A B C and or
* A B or C and

(That's RPN - Reverse Polish Notation. `A` pushes A on the stack, `B` pushes B on the stack, `or` pops 2 values off the stack and applies the OR operation on them, then pushes that on the stack. The result of the calculation is that one thing is on the stack and that is your answer).

isn't ambiguous and yet does not require parentheses. But, while I'm not a psychologist, I find it natural that it is easier to understand operations if the operands are as close to the operator as possible. This isn't always the case with RPN. That's presumably why most languages don't go for this (stuff like PostScript and Forth - stack based languages, really are written like this, though!)