There's also a lot of work going on in that direction right now. I'd check out NamedDims.jl[1] and AxisArrays.jl[2]. This approach is more similar to an EinSum type apprach than you seem to realize though.

The main difference between this sort of approach and the approach in an EinSum esque package is that these packages actually encode the name of the dimensions in the type signature of the array whereas an Einsum-esque approach, the names are just temporary labels for the purposes of the macro call.

[1] https://github.com/invenia/NamedDims.jl

[2] https://github.com/JuliaArrays/AxisArrays.jl

(Dev of NamedDims here) Currently having a (mostly in my head) debate about adding automatic permutation based on names to make operations legal if there is permutation of names that is legel. which would result in `*` act kinda like tensor contraction (but only for matrix matrix / matrix vectors)

Also towards adding something like, making einsum work where you just specify the left-hand side of the einsum and then it uses the encoded names. (Rather than the temporay labels)

PRs to add that feature are welcome

In physics it's pretty common to use different sets of symbols for special indices (most commonly latin for purely spatial dimensions and greek for space-time dimensions).

It should also be noted that the original use of Einstein notation had all the indices refer to the same thing (it refers to some basis of the underlying vector space). I'v seen some ML papers where this was very much not the case. Obviously in those situations you should be very clear about which index means what.

SQL has no row/record names, only column/field names, in proper SQL most of the naming would go inside field values. Doing numerically intensive work this way usually requires both a lot more code (long queries with lots of joins) and a huge performance costs, unless your problems are pretty small.

Pandas is somewhere halfway that and raw matrix/numpy math, automatically aligning dataframes by row and column names first before doing computations. Even though performance is usually closer to numpy than SQL, the extra overhead is sometimes large enough for people to drop down to plain numpy.

As others mention there's alternative approaches. For someone with a physics background thoughm it's very natural to think of matrix - or rather tensor, i.e. more than two indices - operations with indices - it's how we work in (general) relativity and some condensed matter physics. So while obscurity depends on your background, it is sometimes a bit finicky - I can't count the number of times I switched indices around or wrote an 'i' instead of a 'j' but that's something that I deal with with testing (mostly property-tests in physics).

It's not optimal, but it's the best I know and named-indices would have their drawbacks too.