5 ms·

I was recently implementing a geometry algorithm which I looked up on quora. It was described using typical vector notation, using r,s . t,u. Since I referenc

I was recently implementing a geometry algorithm which I looked up on quora. It was described using typical vector notation, using r,s . t,u. Since I referenced the algorithm in the comments, I decided to use these same variable names in my code. I think this is the right choice, but my code reviewer didn't. But he didn't click on the quora link. Why is okay for mathemeticians to abbreviate things but programmers? Is it because they deal in more abstract entities where the name is irrelevant?

jordanlev 10y ago
Probably has to do with decades (centuries?) of knowledge that is passed on in a somewhat consistent and rigorous way. Programming is a relatively new field, with tons of self-taught practitioners.
potatolicious 10y ago
> "Is it because they deal in more abstract entities where the name is irrelevant?" Partially, but also because math equations don't really have strong maintainability needs. Another mathematician isn't going to walk in 6 months later, get confused, and blow up the universe. Though I'd argue that in fact math equations should be better named. They're rather abstractly named as a matter of convention, but they would be more easily understandable in many cases if variables were more carefully named. Another risk of "porting" geometry algorithms, especially complex ones, directly from their mathematical expressions, is that you don't gain insight into why they work. This makes debugging later difficult, since nobody who wrote the code actually understood what the algorithm was doing. Forcing yourself to rename variables into something sensible will also force you to understand the mechanics of what's happening.
- hugozap 10y ago
  >they would be more easily understandable in many cases if variables were more carefully named A mathematician already knows the notation, so a a long mathematical expression with descriptive names will not make it more easy to understand (if you know the notation). I would argue that it can even make things worse and add cognitive load.
NobleSir 10y ago
>Why is okay for mathemeticians to abbreviate things but programmers? Is it because they deal in more abstract entities where the name is irrelevant? for example, xyz^2 in a piece of written math means something different than it would in a program (in the math case we are obviously not taking the variable "xyz" and squaring it). I guess what I am trying to say with this example is that perhaps variable names in math are one symbol because concatenation, in many cases, already means "multiply".
hkjgkjy 10y ago
> Why is okay for mathemeticians to abbreviate things but programmers? I think you want to add a "not" before "programmers in the end of your sentence.
colordrops 10y ago
> Is it because they deal in more abstract entities where the name is irrelevant? That sounds right. Also, there are standards for variable names that everyone is familiar with in math, so those letters actually have meaning. As most of my code is not purely for implementing pure math algorithms, I haven't almost ever written code where a variable couldn't have been named with a word describing it or its use. It makes understanding and maintaining the code a lot easier when it is self-documenting.
bhollan 10y ago
...So if a Triangle is composed of points "Steve, Alice, and Bob,"...
hkjgkjy 10y ago
I theorize it's because math as we know it was written down on paper and blackboards. Those mediums don't have auto-complete, like any good code editor does. I wish math notation would be replaced by s-expressions - easy to type and only like 3 concepts to learn for fluency.
philosoft 10y ago
I suppose it's because a proof is contained within itself while a computer program may interact (in this case with another component within the same application) in non-obvious ways. Clarity in variable names helps to prevent this behavior, although it doesn't completely eliminate the risk.
dang 10y ago
In math, notations are designed to make statements about the problem domain concise. Once you pass a certain degree of concision, longer names impede readability rather than enhancing it. That is because the ability to take in an entire complex expression or subexpression at a glance tells you things—and lets you see patterns—that wouldn't be as apparent if longer names were used. Programmers in the APL tradition understand this, but most programmers do not. (Many refuse to believe it's possible when they hear about it!) In software, programmers have grown accustomed to a notion of readability that derives from large, complicated codebases where unless you have constantly repeated reminders of what is going on at the lowest levels (i.e. long descriptive names) there is no hope of understanding the program. In such a system, long descriptive names are the breadcrumbs without which you would be lost in the forest. But that is not true of all software; rather, it's an artifact of the irregularity and complexity of most large systems. It's far less true of concise programs that are regular and well-defined in their macro structure. In the latter kind of system, there's a different tradeoff: macro-readability (the ability to take in complex expressions or subprograms at a glance) becomes possible, and it turns out to be more valuable than micro-readability (spelling out everything at the lowest levels with long names). It also turns out that consistent naming conventions give you back most of what you lose by trading away micro-readability, and consistent naming conventions are possible in small, dense codebases. That of course is also how math is written: without consistent naming conventions and symmetries carefully chosen and enforced, mathematical writing would be less intelligible. Edit: The fact that readability without descriptive names is widely thought to be impossible is probably because of how little progress we've made so far in developing good notations, and tools for developing good notations, in software. This may not be so hard to understand: it took many centuries to develop the standard mathematical notations and good ways of inventing new ones to suit new problems. Mathematics is the most advanced culture we have in this respect, and in computing we're arguably still just beginning to retrace those steps. If we wrote math the way we write software, mathematics as we know it wouldn't be possible. Edit 2: The best thing on this is Whitehead's astonishingly sophisticated 1911 piece on the importance of good notation: http://introtologic.info/AboutLogicsite/whitehead%20Good%20Notation.html http://introtologic.info/AboutLogicsite/whitehead%20Good%20N.... If you read it and translate what he's saying to programming, you can glimpse a form of software that would make what people today call "readable code" seem as primitive as mathematics before the advent of decimal numbers seems to us. The descriptive names that people today consider necessary for good code are examples of what Whitehead calls "operations of thought"—laborious mental operations that consume too much of our limited brainpower—which he contrasts to good notations that "relieve the brain of unnecessary work". Applying Whitehead's argument to software suggests that we'll need to let go of descriptive names at the lowest levels in order to write more powerful programs than we can write today. But that doesn't mean writing software like we do now, only without descriptive names; it means developing better notations that let us do without them. Such a breakthrough will probably come from some weird margin, not from mainstream work in software, for the same reason that commerce done in Roman numerals didn't produce decimal numbers.
SatvikBeri 10y ago
Math is verb-oriented, so you shorten the variable names to make the structure clear. Most programming is noun oriented, so you clarify variable names at the expense of taking attention away from structure. Math does name its nouns, but those tend to be structures rather than variables (groups, rings, fields etc.)
santaclaus 10y ago
I find that as a piece of code skews more math- and geometric- centric, the variable names skew more towards math-like brevity as well. To some degree this is due to historical technical limitations (LAPACK and Fortran being one extreme -- dgbsv anyone?), but I see a ton of contemporary production code with one letter variable names. R is a rotation, n is a normal, p is momentum, whatever. I think a lot of the historical notation conventions carry over to code, and most peeps working in the domain day to day are down with whatever baggage is brought along. This is fine until you try to read francophone code... try reading a French a thesis and you'll find that they spur all conventions that the rest of the world has agreed upon :).
brador 10y ago
I'd expect that to be a prefixed variable with a comment of the link: link to the post you got it from here Vec_r, Vec_st, Vec_u If you just used the raw letters that's jank. Single letter variables should only be used in very short code blocks or loops.
drxzcl 10y ago
I write a lot of code like that. Usually I start off with a huge comment block, detailing what the function does, outlining the algorithm used and explaining the notation. Only then I include both the link to the paper and and the full citation. It's about as much work as writing the code in the first place, but it has saved me a lot of times when I or someone else had to go and work on it.

jordanlev 10y ago

Probably has to do with decades (centuries?) of knowledge that is passed on in a somewhat consistent and rigorous way. Programming is a relatively new field, with tons of self-taught practitioners.

potatolicious 10y ago

> "Is it because they deal in more abstract entities where the name is irrelevant?" Partially, but also because math equations don't really have strong maintainability needs. Another mathematician isn't going to walk in 6 months later, get confused, and blow up the universe. Though I'd argue that in fact math equations should be better named. They're rather abstractly named as a matter of convention, but they would be more easily understandable in many cases if variables were more carefully named. Another risk of "porting" geometry algorithms, especially complex ones, directly from their mathematical expressions, is that you don't gain insight into why they work. This makes debugging later difficult, since nobody who wrote the code actually understood what the algorithm was doing. Forcing yourself to rename variables into something sensible will also force you to understand the mechanics of what's happening.

hugozap 10y ago
>they would be more easily understandable in many cases if variables were more carefully named A mathematician already knows the notation, so a a long mathematical expression with descriptive names will not make it more easy to understand (if you know the notation). I would argue that it can even make things worse and add cognitive load.

NobleSir 10y ago

>Why is okay for mathemeticians to abbreviate things but programmers? Is it because they deal in more abstract entities where the name is irrelevant? for example, xyz^2 in a piece of written math means something different than it would in a program (in the math case we are obviously not taking the variable "xyz" and squaring it). I guess what I am trying to say with this example is that perhaps variable names in math are one symbol because concatenation, in many cases, already means "multiply".

hkjgkjy 10y ago

> Why is okay for mathemeticians to abbreviate things but programmers? I think you want to add a "not" before "programmers in the end of your sentence.

colordrops 10y ago

> Is it because they deal in more abstract entities where the name is irrelevant? That sounds right. Also, there are standards for variable names that everyone is familiar with in math, so those letters actually have meaning. As most of my code is not purely for implementing pure math algorithms, I haven't almost ever written code where a variable couldn't have been named with a word describing it or its use. It makes understanding and maintaining the code a lot easier when it is self-documenting.

bhollan 10y ago

...So if a Triangle is composed of points "Steve, Alice, and Bob,"...

hkjgkjy 10y ago

I theorize it's because math as we know it was written down on paper and blackboards. Those mediums don't have auto-complete, like any good code editor does. I wish math notation would be replaced by s-expressions - easy to type and only like 3 concepts to learn for fluency.

philosoft 10y ago

I suppose it's because a proof is contained within itself while a computer program may interact (in this case with another component within the same application) in non-obvious ways. Clarity in variable names helps to prevent this behavior, although it doesn't completely eliminate the risk.

dang 10y ago

In math, notations are designed to make statements about the problem domain concise. Once you pass a certain degree of concision, longer names impede readability rather than enhancing it. That is because the ability to take in an entire complex expression or subexpression at a glance tells you things—and lets you see patterns—that wouldn't be as apparent if longer names were used. Programmers in the APL tradition understand this, but most programmers do not. (Many refuse to believe it's possible when they hear about it!) In software, programmers have grown accustomed to a notion of readability that derives from large, complicated codebases where unless you have constantly repeated reminders of what is going on at the lowest levels (i.e. long descriptive names) there is no hope of understanding the program. In such a system, long descriptive names are the breadcrumbs without which you would be lost in the forest. But that is not true of all software; rather, it's an artifact of the irregularity and complexity of most large systems. It's far less true of concise programs that are regular and well-defined in their macro structure. In the latter kind of system, there's a different tradeoff: macro-readability (the ability to take in complex expressions or subprograms at a glance) becomes possible, and it turns out to be more valuable than micro-readability (spelling out everything at the lowest levels with long names). It also turns out that consistent naming conventions give you back most of what you lose by trading away micro-readability, and consistent naming conventions are possible in small, dense codebases. That of course is also how math is written: without consistent naming conventions and symmetries carefully chosen and enforced, mathematical writing would be less intelligible. Edit: The fact that readability without descriptive names is widely thought to be impossible is probably because of how little progress we've made so far in developing good notations, and tools for developing good notations, in software. This may not be so hard to understand: it took many centuries to develop the standard mathematical notations and good ways of inventing new ones to suit new problems. Mathematics is the most advanced culture we have in this respect, and in computing we're arguably still just beginning to retrace those steps. If we wrote math the way we write software, mathematics as we know it wouldn't be possible. Edit 2: The best thing on this is Whitehead's astonishingly sophisticated 1911 piece on the importance of good notation: http://introtologic.info/AboutLogicsite/whitehead%20Good%20Notation.html http://introtologic.info/AboutLogicsite/whitehead%20Good%20N.... If you read it and translate what he's saying to programming, you can glimpse a form of software that would make what people today call "readable code" seem as primitive as mathematics before the advent of decimal numbers seems to us. The descriptive names that people today consider necessary for good code are examples of what Whitehead calls "operations of thought"—laborious mental operations that consume too much of our limited brainpower—which he contrasts to good notations that "relieve the brain of unnecessary work". Applying Whitehead's argument to software suggests that we'll need to let go of descriptive names at the lowest levels in order to write more powerful programs than we can write today. But that doesn't mean writing software like we do now, only without descriptive names; it means developing better notations that let us do without them. Such a breakthrough will probably come from some weird margin, not from mainstream work in software, for the same reason that commerce done in Roman numerals didn't produce decimal numbers.

SatvikBeri 10y ago

Math is verb-oriented, so you shorten the variable names to make the structure clear. Most programming is noun oriented, so you clarify variable names at the expense of taking attention away from structure. Math does name its nouns, but those tend to be structures rather than variables (groups, rings, fields etc.)

santaclaus 10y ago

I find that as a piece of code skews more math- and geometric- centric, the variable names skew more towards math-like brevity as well. To some degree this is due to historical technical limitations (LAPACK and Fortran being one extreme -- dgbsv anyone?), but I see a ton of contemporary production code with one letter variable names. R is a rotation, n is a normal, p is momentum, whatever. I think a lot of the historical notation conventions carry over to code, and most peeps working in the domain day to day are down with whatever baggage is brought along. This is fine until you try to read francophone code... try reading a French a thesis and you'll find that they spur all conventions that the rest of the world has agreed upon :).

brador 10y ago

I'd expect that to be a prefixed variable with a comment of the link: link to the post you got it from here Vec_r, Vec_st, Vec_u If you just used the raw letters that's jank. Single letter variables should only be used in very short code blocks or loops.

drxzcl 10y ago

I write a lot of code like that. Usually I start off with a huge comment block, detailing what the function does, outlining the algorithm used and explaining the notation. Only then I include both the link to the paper and and the full citation. It's about as much work as writing the code in the first place, but it has saved me a lot of times when I or someone else had to go and work on it.