It makes it WAY easier to understand exactly why !(a || b) == !a && !b.
Bob and Sally are things that people already understand and relate to. a and b are not, so there is an extra layer of indirection there when attempting to reason about them.
> Bob and Sally are things that people already understand and relate to.
People understand they're people's names. But that's not a relevant detail for the equation, so why add that to the problem? It complicates, rather than simplifies, my understanding of it.
> !(Milk || Sugar) == (!Milk && !Sugar), duh.
I don't get what the 'duh' is. You've added nothing to the equation! They're just different names!
`with_milk` and `with_sugar` are booleans that people have (lots of) experience with. this seems to help us think about this stuff – we've seen how milk/sugar "work" many times, and we've already internalized some model of that situation – we already "get it" on an intuitive level. hence, reusing that model for general Boolean variables reduces the cognitive effort required[0].
for a similar example, see [1]. summary: a study presented people with a logical problem. they failed miserably if the question was about abstract math-y stuff, but got it right most of the time if the variables were like `X is underage` and `X can buy beer` (explained in the "Policing social rules" section)
---
[0] as a bonus, we can quickly sanity-check if our reasoning is correct – if there's `no (milk or sugar)` in my coffee, there's obviously `(no milk) and (no sugar)` in it!
No. a and b are things I better understand - they're just "two facts otherwise unspecified". Sally and Bob bring with them all this baggage about humans and names and stuff, so it's kind of stupid to use them as descriptors. Two things: firstly, everybody and their grandma knows about de Morgan's laws, so this is a bad example, and secondly, humans best learn abstract ideas through concrete examples, yes, but if you really need to explain something using examples like "Milk" and "Sugar", then that is best done in comments, not in the code, whose very purpose is to unambiguously specify the abstract idea.
This brings up an interesting idea, though - are there any programming languages that "learn" what the user wants by example? What would that even look like?
I'm with them, and if I had to boil it down to one sentence: Zero mental overhead for representing the idea.
I think visually for anything logic-based - shapes, lines, venn diagrams, etc - so using such abstract no-meaning variables gives me nothing to put into that mental image. So unless the logic concept is familiar enough, I have to invent something for the variable before I can place it in the construct, in order learn the construct.
Once the logic construct is familiar to me, I have no issues with the abstract variables at that point.
