> 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.

Instead of

      E = m * c^2

they seem to prefer bullshit like

      thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum,2)

Some part of that is bad namespace handling, remove the namespaces and it already looks better:

      thing->Energy = thing->Mass() * pow(speedOfLightInVacuum, 2)

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.

> E = m * c^2

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.

I suppose you have the same problem when reading this comment too.

no, I do not mistake regular text with mathematical formulas. My problem is that I read code as if it was mathematical formulas.

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.

http://www.ccs.neu.edu/home/samth/fortress-spec.pdf

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.