That’s because it fundamentally doesn’t actually impact all that much.
By most people’s account, the actual coding part of programming isn’t really a majority of their time. Domain research, speccing, debugging, testing, planning, etc. the microscopic savings in key presses are just really such a strange thing to even debate about when you think about it.
Major tersness pushes also tend to cause “symbol soup” and, personally, I find symbol soup very hard to digest.
Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.
I can't find the study I was thinking about, but here are two other studies I found. Neither study directly supports what I had recalled, but one study concludes longer names are more productive and the other concludes shorter names. :) How well these academic studies apply to production code is another question...
In this paper, we investigate the effect of different identifier naming styles (single letters, abbreviations, and words) on program comprehension. We conducted an experimental study with 72 professional C# developers who had to locate defects in source code snippets. ... We found that word identifiers led to a 19% increase in speed to find defects compared to meaningless single letters and abbreviations, but we did not find a difference between letters and abbreviations.
names used in existing production code are long enough to crowd programmer’s short-term memory. This provides evidence that software engineers need to consider shorter, more concise names. As the study considers individual names extracted from production code, it tends to underestimate the demand on memory because there is no need to remember context as well.
You’re right, and that’s part of the reason I remarked my comment’s shallowness. It was more of a personal lament rather than a strong criticism of what looks like a really interesting language.
