I think you're confusing terseness with efficiency.
There's no guarantee that this code compiles to especially efficient binary. Meanwhile, every coder I know considers this to be a significant cause of bugs. A language that makes it easy to write bad code that's hard to see sucks.
a := b
if (a <> 0) then
end if
is unlikely to be less efficient (when compiled) than
if (a = b){
}
The first example is HIGHLY unlikely to be an accident, whereas the second is quite possibly an accident, and it will waste someone's time figuring out whether it is or not one day.
Similarly:
a+=1
may be a very convenient construct, but there's no reason to expect it to compile to more efficient code than
a:=a+1
and
if (condition)
won't compile more efficiently than
if (condition == true)
C was designed to minimize keystrokes in large part because the guys who designed it were working over a very slow teletype connection and not because having unreadable code was deemed a virtue of itself.
There's no guarantee that this code compiles to especially efficient binary. Meanwhile, every coder I know considers this to be a significant cause of bugs. A language that makes it easy to write bad code that's hard to see sucks.
a := b
if (a <> 0) then
end if
is unlikely to be less efficient (when compiled) than
if (a = b){
}
The first example is HIGHLY unlikely to be an accident, whereas the second is quite possibly an accident, and it will waste someone's time figuring out whether it is or not one day.
Similarly:
a+=1
may be a very convenient construct, but there's no reason to expect it to compile to more efficient code than
a:=a+1
and
if (condition)
won't compile more efficiently than
if (condition == true)
C was designed to minimize keystrokes in large part because the guys who designed it were working over a very slow teletype connection and not because having unreadable code was deemed a virtue of itself.