# Why is there no or or and ?

Nick Sabalausky a at a.a
Fri Feb 17 09:27:27 PST 2012

```"F i L" <witte2008 at gmail.com> wrote in message
news:iylkhrwcbscmfwsdxljg at forum.dlang.org...
> Nick Sabalausky wrote:
>>
>> You're talking about very minor details that are trivial to learn (I was
>> only about 12 or 13 when I learned C). The prodictivity drop in these
>> cases is *purely* a *minor* upfront cost, and with no ongoing cost (but
>> does have ongoing *benefits* because it's designed specifically with
>> *it's own* domain in mind instead being hampered by unnecessary ties to
>> some other domain).
>
> I just don't see an argument for why we *shouldn't* make mathematical
> operations in code match those we where taught as children as close as
> possible.
>

When all else is equal, yes, certainly. Which is why we use + as addition,
for example. But all else is often not equal. For instance, ";" is much more
noticable than "." so it's a much better choice for large-grained separation
(ie, separating statements).

>
> yes i agree. I'm not really a fan of using ':=' for assignment because of
> it's keystroke length, even if it *does* make more sense. Still, I don't
> see why '==' couldn't be 'is' and '!=' couldn't be 'not'. Thought this
> might get hard to read with all the 'and'/'or's everywhere:
>
>     a: = 0
>     b: = new Foo
>     c: = "Bar"
>
>     case a is 0 and b not null and c is "Bar" { ... } // hard to read
>     case a == 0 and b !is null and c == "Bar" { ... } // better than:
>     case a == 0 && b !is null && c == "Bar" { ... }

I find:

case a == 0 && b !is null && c == "Bar" { ... }

much easier to read than:

case a == 0 and b !is null and c == "Bar" { ... }

Since the former uses a totally different character set for the operators,
my eyes can parse it at a glance. With the latter, I have to actually go
through and read it. The "and" and "or" just visually blend together with
all the other words and variables.

```