A lot of the choices in Go (and its standard formatting with gofmt) were made with all of these things in mind, not just the raw textual efficiency in mind.
But then you still need to adjust for skill levels, and that seems a bit circular.
I think we're far from being able to measure this accurately.
Japanese does not have key words that are already in English. This is why it's generally considered harder for an English speaking person to read Japanese than to read some simple code.
There are orders of magnitude more people who will program in future than which program now. We should absolutely design things around those people.
Edit for natedad: 100% of people that fixed a bug were non-programmers at some point.
But that's a separate question from how easy it is to use a language after you've already learned it. The studies to measure these questions would need to be designed differently.
On the other hand, these questions do overlap. People who know a language don't stop learning; they get better at using it with practice. Also, people who use a language occasionally need to switch gears going back to it and need to relearn things.
> NateDad: You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence:
Careful. You might be the one here who haven't considered some obvious things.
I think parent as well as dagw's comment (Does that mean that J/K/APL are the objectively best programming languages?) explaint perfectly well why what you wrote where flawed.
- Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue, with a very different effect on parsing efficiency, than the use of unnecessary tokens.
- Of course existing programmers have biases. Measure parsing efficiency using people who aren't already programmers.
Responding to natedad below (rate limit):
> There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier.
Which ones?
> There's more to designing a language than making it use as few tokens as possible...
Yes, but none of those things mean that efficiency is not important.
Responding to reitanqild:
My statement 'Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue' also neatly covers J/K/APL.
If there's anything else you've think I've not responded to, please actually state exactly what it is.