this is is not the world where everybody lives. I live mostly in the world of math books, where all variables are single letters (which is the main difference here, and not the use of unicode). I tend to find code written by non-mathematicians ridiculous and unreadable.
Instead of
E = m * c^2
thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum,2) thing->Energy = thing->Mass() * pow(speedOfLightInVacuum, 2)
auto mass = thing->Mass();
auto c = speedOfLightInVacuum;
thing->Energy = mass * pow(c, 2);
// or thing->Energy = mass * c * c;
// or thing->Energy = mass * c**2; (for languages that support it)
You're not wrong: it's a definite flaw of many programming styles (and programmers!) that they're "too wordy". But it's also true that mathematics can get by with a bit of ambiguity that humans can handle that computers can't.
The problem then occurs when you work in a multidisciplinary group and 'everybody' wants to use 'p' or 'c' or whatever mean the the super obvious thing it means in their field and you have to remember what each letter means in 6 different fields and the 'p' in function f means something completely different from the 'p' in function g.
And that's OK. The 'x' in mathematics means completely different things depending on the equation. That's what comments are for, to explain the meaning of the local variables on each function.
// E: energy of the thing
// m: mass of the thing
// c: constant representing the speed of light in vacuum
E = m * c^2
So, for example, xˆy could be written as x superscript y. SUM[i<-1:n, j<-1:p, prime j] a[i] xˆj was more elegant as a big sigma with the ranges at the bottom, etc.