x86 and probably most if not all assembler programming certainly does use a limited number of registers and, certainly, by that token you are restricted to a small number of names (for the registers). However:
When storing variables into RAM, you use different names - which makes it possible to track what’s going on, since things only sit outside of RAM for a short while for most uses.
Those are long names.
Assembler was abandoned for a reason.
Mathematics has no such hardware restrictions.
And note, I enjoy coding in assembler.
This is simply a description of the way that things are. In no way does it contain any argument that the current methodology is better nor optimal for any particular purpose.
Likewise, I could have said back in the day, “goto is intended for a true programmer and a true programmer understands its value and when to use it and not to use it. A person who cannot safely use the functionality simply shouldn’t be a programmer.”
In some senses that may be true. But there is no actual value in disenfranchisement. The friendlier languages allow people who are less capable to be productive in the field - even though they’re poor at it - and that allows bad code to be created. So you could say that they shouldn’t have had the tools to get involved. But, even if we assume that there’s no such need for bulk labor in mathematics as there is in programming, it’s notable that even hardcore programmers who could use goto safely, generally prefer high level languages over assembler and are more productive with them.
Unless you want to argue that assembler allows people to be more productive, I don’t see your argument.
I've thought about this in the past, and I'd expand on your call for clearing up variable names. With digital docs a lot could be done to improve the readability of math papers (also, pagespace isn't at such a premium). Getting away from wood pulp you can have (off top of my head):
[ul]
[li]hypertext links back to where the formula etc was first introduced when it’s referenced (some papers have this capability; but I can’t easily get back to my jump-off point)[/li][li]expandable/collapsable proof boxes[/li][li]the whole paper collapsible to an outline form, for easy overview of concept/logic flow; this, all the way to tunable detail levels–I want to view the paper at detail level “X”; this might even involve supplementary summary text appropriate to that level of detail[/li][li]callable / invokable summary sheets, with eg main formulas, main theorems, variables (also where they are introduced)[/li][li]difficulty markers, to include depth of reference (eg if a proof is “see [ref]”, which in turn leads to ten other references to allow the reader of a given background to understand it (rrrggh!), or eg the proof hinges on crucial details from Wiles’s proof of Fermat’s Last Theorem, then that gets a high difficulty rating/marker; this vs. simple algebraic manipulation to prove something would get a low difficulty marker)[/li][li]maybe some color coding for certain stuff (that doesn’t make the eyes bleed; no yellow!)[/li][li]“teaching papers” in which the mathematician goes “full verbose”, allowing a broader swath of audience to follow along (instead of just peers at the same level of expertise)[/li][/ul]
What's the drawback? It takes more time for the author.
Re. computer science, 100% of the programs in The Art of Computer Programming - an excellent book! - are in assembly language:
My only comment is that assembly language is still a high-level, human-comprehensible language; the actual CPU low-level language is some form of machine code (supposedly old-school programmers were able to bang it out without relying on crutches like a symbolic assembler).
If you are still talking about x86, those are labels and are abandoned during the link pass.
Assembler is alive and well, and always will be. There are plenty of embedded systems programmers who still use low level languages, and so long as machines still run new code, something must produce machine-readable code. Kids still learn assembly in school - how else will you play breakout on your TI-84?
Right you are. Programming is the one with hardware restrictions, although these are implementation-specific.
I am contesting your premise. Current methodology does not definitively favor long descriptive names. That is just your experience. There are still K&R C purists, assembler programmers, and even mathematicians who write code. There are plenty of computer science papers which use single letter variables. Questions about programming standards are likely to ignite holy wars on a programmer forum, but the truth of the matter is that most standards will be better in some situations and worse in others.
Further, all of the reasons mathematicians use single-letter variables hold true in programming. There already exists a major branch of mathematics which is ‘more like programming’. It is called theoretical computation or theoretical computer science, and plenty of those papers use single-letter variables. Not because paper is expensive, but for a myriad of other reasons:
[ul][li]It takes less time to write fewer letters[/li][li]The intended audience generally knows what the single letters mean[/li][li]It is easier to fit on a printed page - journals still publish on letter-size paper, even if electronic[/li][li]It is shorter and therefore easier to see patterns[/li][li]It is easier to drop any preconceived notions about a variable if the name is less descriptive[/ul][/li]
I’m sure there are other reasons, too.
It’s really just war-time computers that were used without assembly language. After the war people working on EDSAC had the brilliant idea to use mnemonics, and the idea stuck.
You can do manual assembly by taking your note paper with written mnemonics and looking up the opcodes yourself. It’s not too hard on smaller instruction sets. But there are less possible opcodes on a Z-80 (still very alive!) than there are for say x86-64. I can fit all of the Z-80 opcodes one double-sided sheet of paper, but there is something like a thousand mnemonics (let alone opcodes) in x86-64. That being said nowadays computers are everywhere and you can just use a Z-80 assembler program.
And then some processors have their own internal “μops” and run internal subroutines in that language to process assembler opcodes.
When I first started out and was writing video games on my trash 80 color computer, I couldn’t afford to buy an assembler (I had to save all summer just to buy my computer), so I wrote in machine code for a long time.
Although the 6809 had relative addressing, I was young and anxious to get stuff done and didn’t understand all of the addressing modes, so I used absolute addressing on a bunch of stuff. When I needed to insert some code it was really annoying.
It’s entirely possible there are analogous uses in math, but IMO the biggest reasons names need to be descriptive in programming is that code needs to be debugged or repurposed, and then you have the issue of “this thing that is supposed to represent force was calculated wrong” - which is easier to determine if you don’t have to guess what variable names mean.
Honestly it’s possible that continuing to use one letter names in mathematical formulae is just an example of jargon/exclusivity among mathematicians.
The force you get hit with is independent of velocity. f=ma means (force exerted on you) = (your mass)(how much the impact causes you to accelerate). Alternately it could also mean (force exerted on bullet) = (bullet’s mass)(how much the impact causes the bullet to accelerate).
If you know that the bullet hitting you is an elastic impact, than the momentum (mv) is preserved, however you still don’t know how mv relates to ma. Actually I believe in a perfect elastic reaction, you would have an infinite force for an instant in time as there would be no period where your momentum was changing.
And? There’s still a thriving saddle-making trade. Does that somehow mean that the car was a bad idea?
Pointing out that things exist doesn’t mean that ‘only’ things should exist or are in some way preferable.
While I will grant that it has been a long time since I read K&R, I’m pretty sure that their example of the world’s simplest application was this:
int main(int argc, char** argv) {
return 0;
}
And it was not:
Ι m(Ι c, Χ** v) {
← 0;
}
APL existed at the time Kernighan and Ritchie developed C, so it’s not like they couldn’t have gone in for a strongly minimalist / symbolic language. If you want to make an argument for hard core technical coding, C is not an example, you would need to use APL or Befunge.
In an abstract sense, I would agree with the argument, but ignoring the concrete example I would point out that this still isn’t an argument for anything.
[quote]
Further, all of the reasons mathematicians use single-letter variables hold true in programming. There already exists a major branch of mathematics which is ‘more like programming’. It is called theoretical computation or theoretical computer science, and plenty of those papers use single-letter variables. Not because paper is expensive, but for a myriad of other reasons:
[ul][li]It takes less time to write fewer letters[/li][li]The intended audience generally knows what the single letters mean[/li][li]It is easier to fit on a printed page - journals still publish on letter-size paper, even if electronic[/li][li]It is shorter and therefore easier to see patterns[/li][li]It is easier to drop any preconceived notions about a variable if the name is less descriptive[/ul][/li][/QUOTE]
I will grant that code prints poorly. Otherwise, none of these is compelling in any way.
The audience understands - Ergo, you have reduced the audience to those who can understand.
Easier to see patterns - The experience from programming languages makes this seem unlikely. The readability of code helps understanding more than the terseness. Obviously, there will be outliers among the population, but it would be a strong minority and likely one with minimal correlation to a love for mathematics, if at all.
Preconceived notions - That is true, but only relevant for pure mathematics and probably irrelevant even there if we are using variable names like edgeCount or functionTangent. The abstract part of pure math is the objects that you are manipulating - sets, nodes, functions, etc. - not the variable names. So long as you are dealing with abstract objects, I don’t see meaningful variable names making any grand difference in how one thinks about the math. (Though, I grant that this is outside of my area of knowledge and experience.)
And while code does print poorly, you now live in the age of GitHub and IDEs. Math might need to modernize.
Actually, I should rewrite this. In doing so, however, first I want to clarify that v should be considered a mixed set of whole values not to be smaller in magnitude than -2[sup]7[/sup] nor greater than 2[sup]7[/sup] - 1 and a null value.
V is the cartesian product of a sets v[sub]0[/sub] … v[sub]c - 1[/sub] and the whole numbers.
Function m() returns whole values in range -2[sup]31[/sup] nor greater than 2[sup]31[/sup] - 1.
m(V) ≔ ← 0 dx
m() may be extended for further processing of inputs in range c.
I was prepared to come into this thread disagreeing with everything, from the title, but I basically agree with the OP about variable names, and have for a long time. Not that it applies in every context, but why on earth should anyone say A^2 = B^2 + C^2 rather than Hypotenuse^2 = First leg^2 + Second leg^2? Why say “m” for “mass” and “p” for momentum and so on, and not just say “mass” for “mass” and “momentum” for “momentum” and so on?
Well, of course there are reasons even in ordinary language that people use abbreviations at times. But there does seem to be an excessive tradition in modern (post-Descartes) math on single variable names when longer names could be more descriptive without introducing significant clumsiness.
For the Pythagorean Theorem, at least, varying contexts is a reason not to use hypotenuse and legs. Expanding to the more generally cosine law with C^2=A^2+B^2+2ABcos(C), hypotenuse doesn’t even mean anything, as the hypotenuse is defined only for right triangles.
If it’s a triangle, it makes mnemonic sense to call the angle opposite side c angle C. That way you avoid the clumsy use of subscripts. Also, if you look at each of the formulae you two wrote for half a second you will see it is obviously incorrect
Back to the general topic, it is an interesting philosophical question what notation is best. Besides the fact that everything is defined, if the article is on graph theory then G is likely to stand for “graph” rather than “group”, E for “edges” rather than “expectation” or “energy”.
We can examine a random sample of (let’s say good) papers to see how they prefer to name variables in practice rather than guess. There is always some tradition in play, of course.
The saddle is not necessary to make a car; you would say that all ink ought to be more suitable for penmanship, perhaps by making it slightly less viscous or quicker to dry, but you do not realize that ink may be used in printers and for art where these properties you despise are useful in other contexts and sometimes even for calligraphy, a form of penmanship.
You can say a specialized form of ink for casual penmanship would be preferred, and likewise you can say a specialized form of mathematics with descriptive names is favorable to programmers. This does not appear to be your position though, you seem to say mathematics in general should have descriptive names like (some forms of) programming.
main()
{
printf("hello, world
");
}
That doesn’t help much since there are no variables, although function names are clearly descriptive. But if we take a look at basically any example, you will see plenty of single letter variable names:
getline(s, lim) /* get line into s, return length */
char s[];
int lim;
{
int c, i;
i = 0;
while (--lim > 0 && (c=getchar()) != EOF && c != '
')
s[i++] = c;
if (c == '
')
s[i++] = c;
s* = '\0';
return(i);
}
index(s,t) /* return index of t in s, -1 if none */
char s[], t[];
{
int i, j, k;
for (i = 0; s* != '\0'; i++) {
for (j=i, k=0; t[k]!='\0' && s[j]==t[k]; j++, k++)
;
if (t[k] == '\0')
return(i);
}
return(-1);
}
It’s not exclusively single-letters, but there are quite a few and most variable names stay under four letters. The user struct in UNIX v6 is instantiated as “u”, for example.
You didn’t address the fact that it takes less time to write (or type) fewer letters, which is by far the strongest of my arguments. I haven’t seen you address this to my satisfaction, as pointed out upthread something as simple as the quadratic equation is unwieldy with descriptive names. How are you going to write the Lagrangian standard model? The answer is that you can’t fit some of the larger equations one one page (or possibly one screen). You would probably have to abstract away parts of the equation, which hurts comprehension and composition time.
I have reduced the audience and I admit it. Mathematics in academia is not accessible to the general public without a some effort to learn the jargon and underlying concepts. That’s why we have schools. Academia should not necessarily be written at a fourth-grade level like newspapers are.
I reject your unconditional distinction between readability and terseness. In your experience the two are different. Look, less symbols take less time to process if you know what the symbols stand for. Others have pointed out that if you understand the concepts, the symbols are rarely if ever a source of confusion.
Regarding preconceived notions, this is especially important in say, category theory which is the basis of polymorphism in programming. This doesn’t mean the variable should be shorter, but in some cases less specific.
I read your post from the bottom up, which was credible, persuasive, and written in clear English. Then I got to the unix example.
An example taken from the hunt-n-peck programming era, that which succeeded the “coding sheet and typing pool” era, illustrating the problems of a “least bad” language evolved rather than designed, which even then neglected both business and theoretic ideas of language design, using ideas largely rejected by modern languages and modern compilers.
We used to believe in “Humours” and blood letting. Most if not all CS students believed that c was superior to Fortran because c had a ++ operator and was much faster than Smalltalk. Using old c examples does not strengthen your argument.
K&R C is definitely not suitable for all purposes, and it does not scale well and requires a few additional conventions. I brought up UNIX as an example of K&R C, because UNIX was quite literally the poster boy of that language (having been developed in part by the Richie in K&R). I brought up K&R C as an example of a programming standard with single-letter variables, and that style is still very much in use. The second edition is still considered by some to be the best book on programming.
Phrase the law of cosines as the law of cosines, and phrase the Pythagorean Theorem as the Pythagorean Theorem. In the law of cosines, all the variables are completely interchangeable, but this is not so in the Pythagorean Theorem. In the Pythagorean Theorem C^2 = A^2 + B^2, it is important that C is the hypotenuse, not A or B. This importance is not conveyed in the naming A, B, C, but might as well be.
[Incidentally, the law of cosines is usually given as -2ABcos(C) instead of +2ABcos(C) as you’ve written, but perhaps the angle you have in mind is the supplementary exterior angle rather than the interior angle traditionally referred to. (I honestly prefer thinking in these terms myself!)]
