[chongli]

Vim, like math notation, is optimized for efficiency. That's great for power users, but it's not what you would use if you wanted to teach someone how to word process.

Vim is a text editor, not a word processor. Additionally, Vim is a tool designed for power users. Mathematical notation is also meant for power users. When we teach mathematics, we introduce the notation gradually, so students have time to pick it up. This is a process which takes decades from Kindergarten through PhD. Just as a Vim user would scoff at being forced to write in Notepad, a mathematics PhD would scoff at being forced to express their ideas in Kindergarten-level mathematical notation.

try imaging Vim where each file mandates its own special keybindings. That's math notation for ya.

That's how Emacs works, and how Vim works when you install filetype-specific plugins.

[nl]

I'm a power user (been programming for 30 years) and I refuse to use vim keybindings.

I have too many things to remember, and there are plenty of options that give me equal power but don't demand that investment from me.

Math isn't like that - I do more math than the average person and I hate having to decipher the annotation. The number of times I've tried to work out if this sigma is the same as the sigma in this other paper frustrates me enormously.

Or the paper that used a accuracy^bar metric as their primary reporting metric, and we couldn't get near it until we found an obscure footnote in an appendix that explained the ^bar metrics were temporally averaged at test time around a known labelled standard (ie, test data was used to optimise the performance).

[chongli]

Mathematics is more general and applicable than Vim, I'll give you that. I wasn't the one who brought in the Vim analogy, however.

It seems like your complaints are with academic papers, not with mathematical notation specifically. This is a problem that is universal to academic papers. Try reading a critical theory paper, for example, and you'll find it's extremely dense with critical theory jargon the authors don't bother explaining at all.

The problem with academic papers is that they aren't intended for a general audience. The authors of papers are often operating in subfields that are so small that they've actually met most of the other people who will be reading their papers. In that situation, conventions and jargon arise naturally among colleagues. Variable names form a part of these conventions such that, in a more common example, sigma will mean standard deviation among statisticians but mean singular value among linear algebraists.

The other problem with academic papers is that the authors generally don't care about reproducibility, consistency, clarity, pedagogy, or even intelligibility. They're optimizing for quantity of papers published, not quality. As long as their expert peer reviewers understand and give the green light for publication, that's good enough.

[nl]

To be honest I think my (and most people on this thread) real complaint isn't with notation per-say (as in Euclidean vs Hilbert notation etc, as discussed by Tao).

It's really about the lazy habits of many who work at the intersection of math and computer science, and use maths to express themselves without defining things.

> The other problem with academic papers is that the authors generally don't care about reproducibility, consistency, clarity, pedagogy, or even intelligibility. They're optimizing for quantity of papers published, not quality. As long as their expert peer reviewers understand and give the green light for publication, that's good enough.

Having worked around this field, I think this (common) perception of publishing doesn't quite capture what is happening. Peer review isn't anything like code review, and software engineers (separate from computer scientists and mathematicians) think that it is.

[Smaug123]

(Irrelevant nit: the phrase is "per se", meaning "by virtue of itself" in Latin.)

[nl]

Yes you are entirely right, and it's outside my edit window to fix.