Is there an excuse for short variable names?

This is a wonderfully lucid and subtle comment. I think any earnest programmer who wants to get better would do well to study your contributions to this thread until they are sure they understand them.

For a domain expert in their domain of expertise, [long explicit names] are overhead.

Once you pass a certain threshold of complexity and/or time-investment, a well-designed program becomes its own domain of expertise. At that point there is great leverage to be had in finding a compact notation suitable for the recurring concepts of the system. In some ways, finding such a notation is how one ensures that the system has a good design and will keep it. As you point out, it (critically) is what enables us to keep more complex things in our heads. It also becomes an intimate part of the creative process – a good notation suggests new concepts and hints at how the system should grow.

Long explicit names are exactly what you don't want when it comes to the core concepts of a well-designed system. They are useful for things that aren't familiar and so need to be spelled out. But in a well-designed system, the most important concepts are familiar and it is a poor use of our limited cognitive capacity to constantly spell them out, for much the same reason that we prefer to say "gas" instead of "liquid hydrocarbons". Since cognitive capacity is our principal bottleneck in software, this is a big deal.

it sounds very programming 101, but I've found getting into the habit of boring old comments at the top of all my methods/functions explaining what the function does, what the input should be, what the output should be, and then simply putting some comments near the top talking about what all the variables are, what they do, why I have them etc. (usually only 4-10 words)...it sounds dumb and time consuming...but this little bit of polish has pulled my ass out of the fire more times than I care to count, and actually helped me write saner code more times than I care to admit (since sometimes writing out the semantics of this stuff helps clarify thoughts that get muddied and confused in the details of code).

you don't have to do this while you're writing the code, often-times just hammering the code out gets you something running, but then doing this after the fact really helps.

Uh, the example in the article is from a numerical computation, and following conventions (typically, from a book, or a research paper, etc) is often a good idea. Just as long as they are not confusing. An example would be using g for the gravitational constant. If they start becoming confusing, can take them out to a namespace (if the language allows it): just like Math/e is a better practice than e, so Physics/g could be better than g. As a previous comment (http://news.ycombinator.com/item?id=5157849) indicates, when used in a short piece of code, quick synonyms can be used, thus g instead of Physics/g (or Physics/Some_Longer_Name).

As mentioned elsewhere in this thread, short-lived names can often be short, too. In some cases they are little more than placeholders. An example is an index for a for-loop that is in fact a "for-each" loop when the language lacks the latter and the index does not have much of a meaning of its own.

After reading many of the responses, I am wondering if there is a difference between the 'business programmers' and the 'scientific/mathematical programmers'. Most of the examples below show code that could have come from physics or maths code. I have noticed that my code (scientific) tends to have much shorter variable names than the code of some of my "not so mathematical" counterparts. Also, 'business' languages like Java and COBOL seem to encourage longer names more than C and FORTRAN.