Nick Sabalausky wrote:
"F i L" <witte2...@gmail.com> wrote in message
news:jzkatvnibtjkcafqs...@forum.dlang.org...
All of the syntaxes you're advocating are every bit as
arbitrary as the ones you're against.
Programming is logic largely based around math.
Yes, it's *based* around math, but it *isn't* math.
English is based largely around German and Latin, and yet it's
neither German nor Latin, nor a mere conjunction of them, nor
can one say that it *should* be. Of course, you can pick that
analogy to death, but the point is, things don't have to
maintain a heavy resemblance to their origin.
Seeing as how we're all educated around with mathematic
symbols as children, a language design which reflects what is
most familiar will be the easiest to initially understand.
Less friction means more productivity.
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.
I've always agreed with the usual reasoning behind ":= and =
instead of = and ==", but in practice I don't like it becase
assignment is so *incredibly* common I don't want it to be a
2-handed 3-keypress "Shift+Keypress and then another keypress".
Just one keypress, thank you. And yes, equality is fairly
common, too, but *UNLIKE MATH*, equality isn't quite *as*
common as assignment. Plus, "==" is even a little easier than
"two keypresses" since it's the same key, not two different
keys.
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" { ... }
