In software, programmers have grown accustomed to a notion of readability that derives from large, complicated codebases where unless you have constantly repeated reminders of what is going on at the lowest levels (i.e. long descriptive names) there is no hope of understanding the program. In such a system, long descriptive names are the breadcrumbs without which you would be lost in the forest. But that is not true of all software; rather, it's an artifact of the irregularity and complexity of most large systems. It's far less true of concise programs that are regular and well-defined in their macro structure.

In the latter kind of system, there's a different tradeoff: macro-readability (the ability to take in complex expressions or subprograms at a glance) becomes possible, and it turns out to be more valuable than micro-readability (spelling out everything at the lowest levels with long names).

It also turns out that consistent naming conventions give you back most of what you lose by trading away micro-readability, and consistent naming conventions are possible in small, dense codebases. That of course is also how math is written: without consistent naming conventions and symmetries carefully chosen and enforced, mathematical writing would be less intelligible.

Edit: The fact that readability without descriptive names is widely thought to be impossible is probably because of how little progress we've made so far in developing good notations, and tools for developing good notations, in software. This may not be so hard to understand: it took many centuries to develop the standard mathematical notations and good ways of inventing new ones to suit new problems. Mathematics is the most advanced culture we have in this respect, and in computing we're arguably still just beginning to retrace those steps. If we wrote math the way we write software, mathematics as we know it wouldn't be possible.

Edit 2: The best thing on this is Whitehead's astonishingly sophisticated 1911 piece on the importance of good notation: http://introtologic.info/AboutLogicsite/whitehead%20Good%20N.... If you read it and translate what he's saying to programming, you can glimpse a form of software that would make what people today call "readable code" seem as primitive as mathematics before the advent of decimal numbers seems to us. The descriptive names that people today consider necessary for good code are examples of what Whitehead calls "operations of thought"—laborious mental operations that consume too much of our limited brainpower—which he contrasts to good notations that "relieve the brain of unnecessary work".

Applying Whitehead's argument to software suggests that we'll need to let go of descriptive names at the lowest levels in order to write more powerful programs than we can write today. But that doesn't mean writing software like we do now, only without descriptive names; it means developing better notations that let us do without them. Such a breakthrough will probably come from some weird margin, not from mainstream work in software, for the same reason that commerce done in Roman numerals didn't produce decimal numbers.

This is an extraordinary (and enticing and often advocated) claim that has, so far, failed to produce the extraordinary evidence. It says something that a person as concerned with notation as Knuth used mathematical notation for the analysis of algorithms and a primitive imperative machine language to describe behaviour.

Imperativeness is a separate matter. One can easily have it without longDescriptiveNames, and although I don't have Knuth handy, I imagine he did.

Partially, but also because math equations don't really have strong maintainability needs. Another mathematician isn't going to walk in 6 months later, get confused, and blow up the universe.

Though I'd argue that in fact math equations should be better named. They're rather abstractly named as a matter of convention, but they would be more easily understandable in many cases if variables were more carefully named.

Another risk of "porting" geometry algorithms, especially complex ones, directly from their mathematical expressions, is that you don't gain insight into why they work. This makes debugging later difficult, since nobody who wrote the code actually understood what the algorithm was doing. Forcing yourself to rename variables into something sensible will also force you to understand the mechanics of what's happening.

A mathematician already knows the notation, so a a long mathematical expression with descriptive names will not make it more easy to understand (if you know the notation). I would argue that it can even make things worse and add cognitive load.

for example, xyz^2 in a piece of written math means something different than it would in a program (in the math case we are obviously not taking the variable "xyz" and squaring it). I guess what I am trying to say with this example is that perhaps variable names in math are one symbol because concatenation, in many cases, already means "multiply".

That sounds right. Also, there are standards for variable names that everyone is familiar with in math, so those letters actually have meaning. As most of my code is not purely for implementing pure math algorithms, I haven't almost ever written code where a variable couldn't have been named with a word describing it or its use. It makes understanding and maintaining the code a lot easier when it is self-documenting.

I wish math notation would be replaced by s-expressions - easy to type and only like 3 concepts to learn for fluency.

It's about as much work as writing the code in the first place, but it has saved me a lot of times when I or someone else had to go and work on it.

link to the post you got it from here

Vec_r, Vec_st, Vec_u

If you just used the raw letters that's jank. Single letter variables should only be used in very short code blocks or loops.

I think you want to add a "not" before "programmers in the end of your sentence.

Math does name its nouns, but those tend to be structures rather than variables (groups, rings, fields etc.)