> living in the world of mostly ascii-limited code this looks exotic
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.
And you can obviously clean it up further by using variables and just write
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)
The issue is that in "E = m c^2", it's obvious from context what everything refers to. In programming languages, that's not necessarily the case. You can have "thing", but also "other_thing" and "array_of_things". And all those things can have many different properties. And those things can be either objects, or pointers to objects.
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.
> 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
I cannot read multiple-letter variables without unconsciously interpreting them as the product of several single-letter variables. It requires a lot of conscious effort that obscures my understanding of the code.
You might be interested in the Fortress language (RIP), whose input allowed, and was canonical rendered using, mathematical notation.
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.
One of the best (or worst, depending on your preference) aspect of Fortress syntax was that it allows juxtaposition as a multiplication operator. Therefore `(n+1)/(n+2)(n+3)` is, as expected, same as `(n+1)/((n+2)*(n+3))`. The exact "reassociation" procedure for juxtapositions is type-dependent, so that `sin(x)(x)` is `sin(x)` multiplied by `(x)` even though both `sin` and the first `(x)` is followed by other expressions.
From the very little work I've done in Mathematica (which was years ago, and I'm not anywhere close to a "real" mathematician), the mathematical formatting was one of the great perks.