Ary Borenszweig wrote:
Imagine you don't have to write semicolons in D. If you have 1000 lines of code
you save 1000 keystrokes
and characters to read.
If you have about 50 delegates in your code you save 200 characters.
I don't think this is more important than the other problems you mention, but
adding bits of characters
here and there ends up saving a lot.
Saving keystrokes is, in my not so humble opinion, a totally bogus metric with
which to judge a programming language.
What matters, in anything other than a language designed for one-liners, is how
the code looks on the page.
For example, we don't just nail photo prints to the wall. We present them with a
matte, then mount in a complementary frame. Cooking is a lot about the
presentation of the food, not just the taste.
I think that source code is a lot about the presentation of it. It should look
good. The way it looks should be an aid to understanding what it does. Correct
code should look right, wrong code should look wrong.
(I've had many experience programmers tell me they can just scan a page of code
and the bugs stand out because they just look wrong. They don't have to actually
understand the code to find the bugs. A language that enhances this effect is a
better language than one that does not.)
For example, it's hard to format code with goto's so it looks right. It's a lot
easier with structured constructs.
There is value in brevity - extra syntactical noise can distract from what the
code is doing. But it can also positively frame and present code. That's what
should be the criteria.
