Single letter variable names (often from different alphabets) and complex expressions that should be broken down would never make it through a code review ;-)
Single letter variable names (often from different alphabets) and complex expressions that should be broken down would never make it through a code review ;-)
Not at all. Formulas in a math paper always come with at least a paragraph of text explaining them. You aren't supposed to read the formula without the explanation.
> Single letter variable names (often from different alphabets) and complex expressions that should be broken down would never make it through a code review ;-)
That's done for readability. The text explains the terms of the formula and the formula concisely summarizes the precise relationship between them.
Consider this classic, very well written paper: https://math.berkeley.edu/~nadler/atiyah.classification.pdf
The “Generalities” section has only one page and hardly any equations, author simply defines notation he uses. And yet, it requires something like 2+ years of prior education in advanced mathematics (either in strong undergrad program, or in a graduate program) to really grasp it. Author even defines his notation: “E [is] the sheaf of germs of regular sections of E, and \Gamma(E) [is] the vector space of global regular sections of E, thus \Gamma(E) = H^0(X, E).”. Sure, he doesn’t define what H^0(X,E) is, but if I told you that it’s the degree zero sheaf cohomology group of E, would that make any difference to you?
I find that this isn't true. I spent quite a few years working on number theory problems on my own, just out of interest. I developed several techniques that I just couldn't understand when other people used them, because they had really weird notations, like |x-Σbⁿdₙ|<ϵ, with no definitions for any of the letters. (Feel free to guess what that means. Hint: nothing to do with set membership.)
Sure, you can work it out if you can compare several different papers, so it's only a barrier for a few days… but it's still a barrier.
The difference is that it is much easier to websearch a concept by name than by notation. "degree zero sheaf cohomology group" is a big handle to search, discover, and learn things with, whereas "H^0(X,E)" is a deadend.
To some extent the Scheme and Haskell communities do this already, because their favored languages are compact enough to allow them to include their programs in more or less conventional math papers.
http://canonical.org/~kragen/sw/dev3/paperalgo is a notation I developed for writing procedural programs with paper and pencil, extending mathematical notation with lightweight notation for classes, methods/functions, assignment, iteration, conditionals, and pattern matching. For many years I have used it whenever I'm writing code on paper or a whiteboard, but still find it harder to read than more traditional notations like Python and Scheme.
In addition to compact code and explanation, it's often useful to have example inputs and outputs (the way spreadsheets and Jupyter notebooks or R notebooks do), as well as proofs.
I think it would be tougher to find anyone willing to read programs written like this. Requiring an explanation to understand the variables is very similar to encoding the variables names and putting a lookup table below. Why force someones eyes to dart back and forth between the program and lookup table, just to get an idea of what the variable are, rather than also including a very rough explanation of what they variables are doing, in the program itself, by giving them meaningful names?
We only have so much working memory. Giving variables names frees up a significant amount.
This, by the way, is probably the main reason math uses single letters for names (with some rules of thumb that hint at the type, like n for an integer, X for a scheme, calligraphic F for a sheaf, etc.).
This was a good lesson for me, I won't do that again and I'm far more verbose now.
My thinking is that maybe math should learn from things like that as well, perhaps expanding equations and being more verbose within the equation instead of an explanation next to it would make maths more accessible to a broader audience.
You shouldn’t really read the equations before understanding what they are about.
They are usually written down to get rid of ambiguities of the natural language.
Same reason one often sees I1 + I2+I3+I4 in estimates. For the moment you actively don't want the mental overload of all the details. You just want to know that there are four terms to be discussed, now forget about all others and let us start looking at the first one.
Similarly long notation/names just do not work well on blackboards/whiteboards.
But it can really help understand the practicalities of it, like any paper involving models, which are pretty numerous outside of pure mathematics. Unfortunately, I've seen many papers that "leave it to the reader" when it comes to equations used, with no translation between variable names and what they actually represents.
mathematics is partially a language (maybe one of the most universal ones), once you learn common conventions, it becomes easier.
Obviously it's no problem for human minds to learn huge numbers of symbols, just like some CJK languages with a large number of ideographs that have to be understood in context.
I do think auto-annotation, as well as other types of interactivity are great, though!
julia> x = 19; w = 5; y = 10x + 2.0w
200.0If I designed a new language from 0, I'd like to allow only single letter variable identifers (possibly with unicode sub-indices and modifiers).
In the nicest possible way - this is absolute madness.
The language could aid you to clarify your code. For example, by forcing each variable to be declared explicitly at the beginning of its scope, on a line all by itself. Then the compiler could put a warning if one of these declarations didn't have a comment.