"F i L" <witte2...@gmail.com> wrote in message
news:iylkhrwcbscmfwsdx...@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.
