Reply
 
Thread Tools Display Modes
  #51  
Old 07-22-2019, 11:39 AM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
In general, I believe that self-documenting code was a move forward. Comments are better, but people never write them; they do better with function and variable names.

But I have also seen it move things back towards spaghetti code, because you're solutions logic across a random assortment of mini functions scattered in no particular order all over the place (and, in one instance I've seen, creating extra layers of objects and factories) and encouraged people to not comment. I received one review asking me to remove a comment in favor of a long function name, for a single line in a short function.

At any rate, whatever the best setup is for code, it's certainly better than what math is doing even if we're still narrowing in on the right answer.

Last edited by Sage Rat; 07-22-2019 at 11:40 AM.
  #52  
Old 07-22-2019, 11:43 AM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by MrDibble View Post
Right from the get-go, you're building on some shaky foundations here:
1) wax tablets, in particular, are endlessly rewriteable.
2) You seem to ignore the chalk+slate tablet/chalkboard combo, again endlessly rewriteable.

Neither of those were particularly difficult to use, either. Or particularly expensive (hell, the Greeks and Romans used wax tablets for letters, bills of lading,even schoolkid's writing practice)
I said that those technologies encouraged brevity (because it's a PITA to write on them). My comments about scratching things out was in the discussion of paper and only paper.
  #53  
Old 07-22-2019, 11:50 AM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by Thudlow Boink View Post
Here's the Wikipedia article for the Gamma function. What would your hypothetical wished-for IDE have given you when you "click the Γ"? Something like this whole article, or a specific part of it, or something else?
Given that we're discussing the language of math, I would presume it to include at least a proof.

Since that language seems to also require the ability to formally state and describe propositions, theories, etc. Some of that might also be in there, depending on how industrious the library writer was feeling.

I might also expect some calculus imports and the ability to click into the proofs of differentiation and such.
  #54  
Old 07-22-2019, 11:58 AM
Thudlow Boink's Avatar
Thudlow Boink is online now
Charter Member
 
Join Date: May 2000
Location: Lincoln, IL
Posts: 27,170
Quote:
Originally Posted by Sage Rat View Post
Given that we're discussing the language of math, I would presume it to include at least a proof.
A proof of what?
  #55  
Old 07-22-2019, 12:00 PM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by PrimalEnvy View Post
Of course it's nonsense. It's actually F=ma. Or sometimes F=d/dt(mv).
Hm. Bizarre. The amount of force I get hit with is independent of the current velocity, just how quickly it's changing? Whether a bullet is traveling at 1 m/h or 1000 m/s, it will have the same force so long as it was traveling at an equivalent difference of speed in the previous measurement period?
  #56  
Old 07-22-2019, 12:05 PM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by Thudlow Boink View Post
A proof of what?
If it's not a thing that needs proving, it's more just a "useful macro" for various purposes, then probably I would expect to see proofs of its ability to fulfill those purposes, similar to unit tests in code.

Last edited by Sage Rat; 07-22-2019 at 12:06 PM.
  #57  
Old 07-22-2019, 12:12 PM
Andy L is online now
Member
 
Join Date: Oct 2000
Posts: 6,514
Quote:
Originally Posted by Sage Rat View Post
Hm. Bizarre. The amount of force I get hit with is independent of the current velocity, just how quickly it's changing? Whether a bullet is traveling at 1 m/h or 1000 m/s, it will have the same force so long as it was traveling at an equivalent difference of speed in the previous measurement period?
Other way around (as I explained a few posts ago). The force you get hit with depends on how quickly your body changes the velocity from the current velocity to zero. Drop a glass onto a concrete floor from a distance of 4 feet - the velocity changes from about 16 feet per second to zero very quickly, and the glass breaks. Drop it from four feet above a cushion and the velocity changes from 16 feet per second to 0 over a significantly longer time - and the class doesn't break. The acceleration before the collision doesn't matter - it's the acceleration (deceleration) during the collision that matters.
  #58  
Old 07-22-2019, 01:09 PM
DPRK is offline
Guest
 
Join Date: May 2016
Posts: 3,479
Quote:
Originally Posted by Sage Rat View Post
Given that we're discussing the language of math, I would presume it to include at least a proof.

Since that language seems to also require the ability to formally state and describe propositions, theories, etc. Some of that might also be in there, depending on how industrious the library writer was feeling.

I might also expect some calculus imports and the ability to click into the proofs of differentiation and such.
It is my no means consistent or universal, but I see that some authors do make at least a token effort to prepare a PDF file with hyperlinks, so that clicking on a mention of "Definition 1.2.3" or "Theorem 4.5.6" takes you to that part of the paper, and clicking on an external reference takes you to the bibliography and/or brings up the actual article in question.

As for basic properties of the gamma function, there may be no references in the paper you read because the author assumes you already know what he or she is talking about, or at any rate can easily look it up. It's not some esoteric function nobody has heard of, in which case one would expect at least a definition and further references.
  #59  
Old 07-22-2019, 04:28 PM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by RaftPeople View Post
Again, researchers study this stuff. The results are unambiguous.
You've stated this twice as fact, and this is GD, so I've gotta call "cite" on this.

Quote:
for example, I saw a study where a "reverse text" function (about 10 lines) was studied by experienced programmers, one group had meaningful variable names and one group did not (e.g. a,b,c,etc.).
10 lines for reverse text? The variable names aren't the real problem in this example. You could do this in a single line of Ruby code (two lines if you're reading from a file).

This is just to call out (again) that best practices are very much context-dependent. It's not an admonition to switch to Ruby, but... if you find yourself spending a lot of time scrupulously naming and commenting functions that could be trivial, maybe you need to be looking at a different toolset.
  #60  
Old 07-22-2019, 06:48 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by HMS Irruncible View Post
You've stated this twice as fact, and this is GD, so I've gotta call "cite" on this.
http://www.cs.loyola.edu/~lawrie/pap...rieICPC06a.pdf
"6 Summary and Future Challenges
The study described in this paper shows that better comprehension is achieved when full word identifiers are used
rather than single letter identifiers as measured by description rating and confidence in understanding."

http://www.diva-portal.org/smash/get...FULLTEXT01.pdf
"The conclusion of this report is that the readability and interpretation of code
was improved by the introduction of certain code styling features. As for code
indentation and syntax highlighting, no visible improvement was observed.
Code commenting, however, caused the subjects to examine the method signatures in a code more thoroughly and thus detecting return-type-related
errors hidden within; a visible improvement. Furthermore, logical variable
naming rids the programmer of the trouble of having to read entire pieces
of code that could otherwise, when used cleverly, be explained by a method
or variable name itself, and thus improved readability and interpretation as
well."


https://www.cs.huji.ac.il/~feit/papers/Names17ICPC.pdf
"In all three methods the time
it took participants to reach comprehension under the
8
control treatment was shorter than the time needed with
the experimental treatment, where variable names were
replaced by a, b, c, and so on."



Quote:
10 lines for reverse text? The variable names aren't the real problem in this example. You could do this in a single line of Ruby code (two lines if you're reading from a file).
You think it's a problem that in some languages, it takes about 10 lines to write a reverse function?

Please help the rest of us understand, why is that the "real" problem? And what exactly about it is the "real" problem?

Do you think a language exists in which every single computable function is smaller in that language than all others? If you don't think that then why did you focus on this combination of one function and the comparison of two specific languages?

Should we switch our 20 million lines of code every time a new language introduces a built in function that saves a few lines? "Hey guys, start the rewrite, there's a new language that does the reverse function in just 3 letters, you don't have to spell out the entire word, you just type in REV"


I was going to ask you how much experience you have, but no need, the question has been answered.
  #61  
Old 07-22-2019, 07:41 PM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by RaftPeople View Post
Do you think a language exists in which every single computable function is smaller in that language than all others? If you don't think that then why did you focus on this combination of one function and the comparison of two specific languages?
You're the one who brought that example to the table. I just responded to it. Bring in some different examples or languages if they would illustrate your point better.

Quote:
Should we switch our 20 million lines of code every time a new language introduces a built in function that saves a few lines?
Having had this conversation many times, I anticipated your question "So should we switch languages". I went to the trouble to preemptively address it in my reply. Behold!
Quote:
Originally Posted by HMS Irruncible
This is just to call out (again) that best practices are very much context-dependent. It's not an admonition to switch to Ruby, but...
So... I'll happily continue this discussion of readability, once you demonstrate an adult grasp of the pre-requisite of... you know... reading.
  #62  
Old 07-22-2019, 09:17 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by HMS Irruncible View Post
Having had this conversation many times, I anticipated your question "So should we switch languages". I went to the trouble to preemptively address it in my reply. Behold!
Yep, I saw that, but you then ended with:
Quote:
if you find yourself spending a lot of time scrupulously naming and commenting functions that could be trivial, maybe you need to be looking at a different toolset.
If your point was not that the language was the "real" problem, why bring this up at all?


So what then is the "real" problem with the 10 line function?
  #63  
Old 07-23-2019, 09:01 AM
Chronos's Avatar
Chronos is online now
Charter Member
Moderator
 
Join Date: Jan 2000
Location: The Land of Cleves
Posts: 84,405
Quote:
Quoth Sage Rat:

Hm. Bizarre. The amount of force I get hit with is independent of the current velocity, just how quickly it's changing? Whether a bullet is traveling at 1 m/h or 1000 m/s, it will have the same force so long as it was traveling at an equivalent difference of speed in the previous measurement period?
Suppose that a major-league pitcher throws a 100 MPH fastball, right over your head, so close that it messes up your hairdo. Does it hurt? Of course not. Why not, given that the ball was moving very fast? Because it was still moving nearly as fast right after its encounter with you: Its velocity had almost no change, so its acceleration was almost zero, and so, by F = ma, it had almost no force exerted on it (and hence, by Newton's Third Law, it likewise exerted almost no force on you). Did it have a significant acceleration at some point before that? Sure, while the pitcher was throwing it, because then, his hand was exerting a force on it.

Now, there are other quantities in physics which do depend on mass and velocity: Momentum is m*v, and kinetic energy is 1/2 m*v^2 . But those are both different things from force (and from each other), and you'd be looking at them for different reasons, to answer different questions. If the baseball does hit you directly in the face or the gut or whatever, it'll be momentum that determines if it knocks you over, and kinetic energy that (more or less) determines how much it hurts.
  #64  
Old 07-23-2019, 11:02 AM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by RaftPeople View Post
Yep, I saw that, but you then ended with:


If your point was not that the language was the "real" problem, why bring this up at all?
To point out for the Nth time (sorry, I guess I should save time by writing "timesThatIHaveSaidThisTh time") that best practices are context-dependent, not universal.

Quote:
So what then is the "real" problem with the 10 line function?
It's difficult to judge code I haven't seen. I can only speak to my process and experience. From your high-level description, the verbosity seems unusually high for the purpose. As a general principle, before I try to make code pretty, I want to make it smaller. Smaller blocks are easier to understand than large blocks, they are easier to isolate and test than large blocks. Deleted code can't fail.

But let's say, for argument's sake, that this function is as good as it can be. Let's even say there's a 5% bonus for speed-reading these 10 times of code. How often are we going to recoup that benefit? How often are we going to decide that "LetsReverseSomeText" has a new responsibility? I would suggest that if the answer is anything more frequently than "never", this changes the character of the discussion entirely.

Saving a nickel on a transaction only matters in proportion to the frequency of the transaction. Context matters.

Last edited by HMS Irruncible; 07-23-2019 at 11:03 AM.
  #65  
Old 07-23-2019, 12:59 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
I'm struggling to reconcile these two posts:
Quote:
Originally Posted by HMS Irruncible View Post
10 lines for reverse text? The variable names aren't the real problem in this example.
Quote:
Originally Posted by HMS Irruncible View Post
It's difficult to judge code I haven't seen.
You seem to imply that 10 lines of code to reverse text is a problem, like that number of lines to achieve that operation is a problem. But you also agree that we can't just change programming languages because some other language can do it in one line.

These are the things you seem to be saying:
1 - 10 lines of code to reverse text is somehow related to the "real" problem (as opposed to the variable names)

2 - Ruby can do it in one line - so that is somehow related to the "real" problem

3 - But you admit we can't just change languages chasing localized advantages and swapping out codebases

4 - And you can't judge code you haven't seen (which is fair)

But, there is a "real" problem with the code that you can see.


I'll let you off the hook, you should have just stated "hmm, 10 lines seems like a lot for that function", as opposed to stating so adamantly that you can see the "real" problem.


Here's the code by the way:
public static void xxx(final boolean[] array,
final int startIndexInclusive,
final int endIndexExclusive) {
if (array == null) {
return;
}
int i = startIndexInclusive<0 ? 0 : startIndexInclusive;
int j = Math.min(array.length, endIndexExclusive) - 1;
boolean tmp;
while (j > i) {
tmp = array[j];
array[j] = array[i];
array[i] = tmp;
j--;
i++;
}
}
  #66  
Old 07-23-2019, 03:30 PM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by RaftPeople View Post
I'll let you off the hook, you should have just stated "hmm, 10 lines seems like a lot for that function", as opposed to stating so adamantly that you can see the "real" problem.
I stated that the variable naming probably isn't the problem. We seem to have a bad disconnect with you inferring things I didn't say, so instead of talking about that, let's talk about the code:
Quote:
Here's the code by the way:
public static void xxx(final boolean[] array,
It's Java? Okay then. Apache Commons has a widely used library that can accomplish that in 1 line (not counting the unavoidable Java boilerplate, but that doesn't really contribute to the variable naming issue anyway).

So, the Real Problem diagnosed: reinvention of wheel. Prescription: use commons.lang, as Java programs typically do. Variable confusion: gone.
  #67  
Old 07-23-2019, 04:05 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by HMS Irruncible View Post
I stated that the variable naming probably isn't the problem. We seem to have a bad disconnect with you inferring things I didn't say,
I asked you three times what is the "real" problem. You avoided answering it every time. Why didn't you just answer the question to clear things up?

Quote:
let's talk about the code:

It's Java? Okay then. Apache Commons has a widely used library that can accomplish that in 1 line (not counting the unavoidable Java boilerplate, but that doesn't really contribute to the variable naming issue anyway).

So, the Real Problem diagnosed: reinvention of wheel. Prescription: use commons.lang, as Java programs typically do. Variable confusion: gone.
LOL. The example code above was taken from that exact library.
  #68  
Old 07-23-2019, 04:40 PM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by RaftPeople View Post
I asked you three times what is the "real" problem. You avoided answering it every time. Why didn't you just answer the question to clear things up?
Why do you keep playing hide-the-ball? Why are you asking me to critique something without seeing it? Why weren't you forthcoming about even the language you were talking about?

Quote:
LOL. The example code above was taken from that exact library.
What point do you believe that you have made here? That you can't lose an argument if you conceal the thing you're arguing about? This has departed the realm of good faith; I'm out.
  #69  
Old 07-23-2019, 06:11 PM
Asympotically fat is offline
Guest
 
Join Date: Jan 2008
Posts: 3,170
Many forms of mathematical notation could certainly be better and there have been attempts to reform some of them, but the nature of maths means that being economic with the number characters so that the important idea sticks out. This sounds to me like a solution in search of a problem.

Take the definition/identity below definition/identity of the Christoffel symbols of the the 2nd kind, which I've delibrately chosen as it is not easy to understand without a little bit of study of the relevant area of maths and in several ways it could be argued that the notation is confusing, but is still used because of its relative economy of symbols (in the context where it is often used, general relativity, it would represent 64 equations with 12 terms in each, though some of those equations would turn out to be the same). Could the OP give indication where they would make it more descriptive?

Γikl = gim(gmk,l + gml,k - gkl,m)

Where:

Γikl is the (i,k,l)th component of the Christoffel symbols of the 2nd kind

gim is the (i,m)th component of the inverse metric tensor

gmk,l/gml,k/gkl,m is the partial derivative of the (m,k)th/(m,l)th/(k,l)th component of the metric tensor with respect to the lth/kth/mth coordinate.

NB m is a dummy indice and is summed over.
  #70  
Old 07-23-2019, 06:50 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by HMS Irruncible View Post
Why do you keep playing hide-the-ball? Why are you asking me to critique something without seeing it? Why weren't you forthcoming about even the language you were talking about?
You stated the "real" problem wasn't the variable names.

I asked what was the "real" problem multiple times.

You ignored it until you provided the impossible but pretty entertaining answer about using the very library that the devs were creating.

And you conclude that it was somehow my fault?



Quote:
What point do you believe that you have made here?
That it was funny (thus the LOL)



Quote:
That you can't lose an argument if you conceal the thing you're arguing about?
There was and is no argument, just a simple question about what you meant when you said the variable names aren't the "real" problem.

A person asking you to explain your statement isn't an argument, it's a one sided request for more information.

I'm still confused about what you originally intended when you said that.



Quote:
This has departed the realm of good faith; I'm out.
What would the exchange have looked like if it was in good faith?

Can you point to anything specific that was in bad faith?
  #71  
Old 07-23-2019, 07:32 PM
Melbourne is offline
Guest
 
Join Date: Nov 2009
Posts: 5,189
Quote:
Originally Posted by glowacks View Post
Computer programs need descriptive variable names because computer programs have a much higher likelihood to be need to be read by people who don't already understand what it is they do. If you don't understand a math paper because you don't understand what the variable names mean, it's highly unlikely that you've studied the subject enough to understand the concepts; only if people use intentionally obtuse variable names, or conventions differ between academic groups, does it become a problem that the target audience is unable to read and comprehend a paper because of bad variable names.
.
It is a well-accepted principle in CS that programs are harder to read than to write: that programs are harder to understand than to conceive: and that if you write a program that is as clever as you can make it, it will be too clever for you to debug.

One of the reasons math is hard is because you have to study the subject enough to memorize the symbology before you can read for content.
  #72  
Old 07-23-2019, 07:33 PM
BigT's Avatar
BigT is offline
Guest
 
Join Date: Aug 2008
Location: "Hicksville", Ark.
Posts: 36,452
Quote:
Originally Posted by HMS Irruncible View Post
Why do you keep playing hide-the-ball? Why are you asking me to critique something without seeing it? Why weren't you forthcoming about even the language you were talking about?
Because the topic is not about specific code. You made a broad claim about variables in every computer language. You argue that descriptive variable names are not useful (except in certain limited cases).

RaftPeople provided direct links to studies to show this is false. Using descriptive variable names greatly sped up comprehension of code in multiple studies. You then moved the goalposts to proving that using 10 lines of code to reverse a string is wrong.

Once again, a blanket claim about all code everywhere, not about any specific code. And one that seems especially ignorant since you assumed the context was one where existing libraries were available, rather than the actual code for those libraries. And it completely ignores the purpose of the study which was about understanding the code, not about whether said code was the best possible code.

You're arguing something that is at odds with programming practices pretty much everywhere. Descriptive variables are the norm in every project I've seen. Because they make code easier to understand. Yes, comments can be good, too. So is structure. So are a lot of things. Good clean code has a lot of factors.

Descriptive variables are part of good clean code, and taught in every introductory course I've ever seen, as well as any book trying to guide people. And there is science--not just your personal opinion--to back that up.
  #73  
Old 07-23-2019, 08:07 PM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by RaftPeople View Post
What would the exchange have looked like if it was in good faith?
You're asking me what it would look like if you argued in good faith? Apparently we're never going to know.
  #74  
Old 07-23-2019, 08:57 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by HMS Irruncible View Post
You're asking me what it would look like if you argued in good faith? Apparently we're never going to know.
Can you point out where I posted something that wasn't in good faith?
  #75  
Old 07-23-2019, 09:29 PM
HMS Irruncible is online now
Guest
 
Join Date: Nov 2004
Posts: 8,279
Quote:
Originally Posted by BigT View Post
You made a broad claim about variables in every computer language. You argue that descriptive variable names are not useful (except in certain limited cases).
Really, you don't see the self-contradiction in the criticism "you made a universal claim! With EXCEPTIONS"? Come on.
Quote:
you assumed the context was one where existing libraries were available, rather than the actual code for those libraries
If we were discussing as adults then we could have separately treated the case "What if you don't have a library"? Instead, he omitted the context and the result was "Gotcha! You don't have libraries!"

If you find that kind of gotcha tactic informative, let me pose one of my own: Go to that github repository where the code is stored. Fork it and make a pull request. Submit a patch demonstrating how the variables in the code ought to be better named. Let's see what the maintainers/community have to say about it.

There's a really easy way to put your money where your mouth is. Who's up for it?
  #76  
Old 07-23-2019, 09:55 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by HMS Irruncible View Post
If we were discussing as adults then we could have separately treated the case "What if you don't have a library"? Instead, he omitted the context and the result was "Gotcha! You don't have libraries!"
How could it possibly be a "gotcha" when I still don't know what your original point was about the "real" problem. For some reason you felt compelled to post publicly that the vars aren't the "real" problem but you still haven't stated what the "real" problem was. Unless your reinventing the wheel problem you mentioned later was the original problem. But it's unclear because of the wording in your later post sounded like it was a new analysis, vs the original.


Either way, it was a funny coincidence. I had no idea the researchers used that code, but I knew they pulled their code from a production source so I thought I would check and it turned out that is where they got it. Pretty damn funny don't ya think?


Quote:
Submit a patch demonstrating how the variables in the code ought to be better named.
Nobody said the variables in that code I showed you are bad.

The researchers modified that code and replaced all of the meaningful variable names with letters like a, b, c, etc.

After they did that, comprehension time was 2x to 3x (jumping from something like 2 to 8 minutes to 7 to 19 minutes (depending on the specific person)).
  #77  
Old 07-24-2019, 09:35 AM
Max S. is offline
Guest
 
Join Date: Aug 2017
Location: Florida, USA
Posts: 1,137
Quote:
Originally Posted by Sage Rat View Post
In programming, if you named your variables 'a', 'b', and 'm', everyone would take you out into the parking lot and shoot you out of a cannon to get you as far away from them as possible. These sorts of names simply make it harder to follow and understand the material. (I have had to work with code like that. It sucked.)
This isn't unheard of with embedded systems and legacy code. At the fundamental level, any Von Neumann architecture has a limited number of actual variables - one for each register, an array for memory, and a stream for the external storage medium. If you make the jump from opcodes to mnemonics, there are still no meaningful variable names. Meaningful naming, as opposed to implimentation-specific standards (such as ecx for iteration), does not enter the picture until you add a linker to resolve labels.

I compare 'pure' mathematics with 'pure' computer science - older papers that have to describe machine code. Is it harder to understand? Yes. But the intended audience and the purpose is different too - they are written for the mathematics community, which demands that everything is well defined. A mathematics paper won't say "plug this into your favorite hash function", it must fully define the formula referenced or point to a specific publication that defines a specific formula. Once you start building layers of abstraction, and assume your audience is familiar with these layers, it ceases to be 'pure' mathematics and becomes a much more specialized field.

~Max
  #78  
Old 07-24-2019, 10:18 AM
Chronos's Avatar
Chronos is online now
Charter Member
Moderator
 
Join Date: Jan 2000
Location: The Land of Cleves
Posts: 84,405
HMS Irruncible, when the question is "How do you write a straightforward function", then the answer "you don't, you use the library function" is critically flawed, precisely because someone still had to write the library function. RaftPeople, with your inadvertent help, just very succinctly pointed out that flaw.
  #79  
Old 07-24-2019, 03:41 PM
naita is offline
Guest
 
Join Date: Jun 2002
Location: Norway
Posts: 6,581
"Mathematics" is a bit vague, but I can tell you as someone who has a degree in programming and make sure I use descriptive variable names when appropriate, who's also taught high schoolers math and physics, that I do not want a reform replacing simple symbols in high school math and physics.

I also wonder if there is anyone who doesn't just call their iterators i, j or n in loops?

Developing and understanding of math and physics involves a lot of working with and rearranging an increasing number of variables by hand. Who wants to derive

d = v_0 *t + 1/2*a*t^2

from v = v_0 + a*t and d = (v_0 + v)*t/2

using descriptive variable names.

Sure you should introduce velocity = distance/time in middle school with those terms, but it's simply not viable to work like that at higher levels.

Even if you do start writing Energy_total = mass*acceleration_due_to_gravity*height + .5*mass*velocity^2 and that simplifies _some_ aspects of understanding the formula, it's still the case that some aspects requires you to have previous knowledge, and that previous knowledge might as well include the conventional symbols.
  #80  
Old 07-24-2019, 04:07 PM
Max S. is offline
Guest
 
Join Date: Aug 2017
Location: Florida, USA
Posts: 1,137
Quote:
Originally Posted by naita View Post
I also wonder if there is anyone who doesn't just call their iterators i, j or n in loops?
I'm sure plenty of people use longer descriptors - anybody who uses an iterator or for-each pattern as opposed to a loop counter (cx/ecx, i/j/k).

Let me google that for you: https://www.google.com/search?q=iterator

The first result is "How to use Iterator in Java? - GeeksforGeeks"

And there we see in all it's beauty a class named "Iterator" instantiated with the descriptor "iterator":
Code:
Iterator iterator = list.iterator();
~Max
  #81  
Old 07-24-2019, 05:01 PM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by Max S. View Post
This isn't unheard of with embedded systems and legacy code. At the fundamental level, any Von Neumann architecture has a limited number of actual variables - one for each register, an array for memory, and a stream for the external storage medium. If you make the jump from opcodes to mnemonics, there are still no meaningful variable names. Meaningful naming, as opposed to implimentation-specific standards (such as ecx for iteration), does not enter the picture until you add a linker to resolve labels.
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:

1) 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.
2) Those are long names.
3) Assembler was abandoned for a reason.
4) Mathematics has no such hardware restrictions.

And note, I enjoy coding in assembler.

Quote:
I compare 'pure' mathematics with 'pure' computer science - older papers that have to describe machine code. Is it harder to understand? Yes. But the intended audience and the purpose is different too - they are written for the mathematics community, which demands that everything is well defined. A mathematics paper won't say "plug this into your favorite hash function", it must fully define the formula referenced or point to a specific publication that defines a specific formula. Once you start building layers of abstraction, and assume your audience is familiar with these layers, it ceases to be 'pure' mathematics and becomes a much more specialized field.

~Max
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.

Last edited by Sage Rat; 07-24-2019 at 05:06 PM.
  #82  
Old 07-24-2019, 05:24 PM
Settimo is offline
Guest
 
Join Date: Jan 2017
Posts: 51
Quote:
Originally Posted by Sage Rat View Post

Trying to read a math paper, you'll come across a formula and have to spend 5 minutes scouring the text to try and find where they introduce the variable, what it signifies, what type it is, what restrictions there are on it, and how it has been initialized. Occasionally, that all seems to be absent all together.
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):
  • 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)
  • expandable/collapsable proof boxes
  • 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
  • callable / invokable summary sheets, with eg main formulas, main theorems, variables (also where they are introduced)
  • 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)
  • maybe some color coding for certain stuff (that doesn't make the eyes bleed; no yellow!)
  • "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)

What's the drawback? It takes more time for the author.
  #83  
Old 07-24-2019, 05:41 PM
DPRK is offline
Guest
 
Join Date: May 2016
Posts: 3,479
Re. computer science, 100% of the programs in The Art of Computer Programming - an excellent book! - are in assembly language:
Quote:
Many readers are no doubt thinking, ``Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days.''

Such people are entitled to their opinions, and they need not bother reading the machine-language parts of my books. But the reasons for machine language that I gave in the preface to Volume 1, written in the early 1960s, remain valid today:
  • One of the principal goals of my books is to show how high-level constructions are actually implemented in machines, not simply to show how they are applied. I explain coroutine linkage, tree structures, random number generation, high-precision arithmetic, radix conversion, packing of data, combinatorial searching, recursion, etc., from the ground up.
  • The programs needed in my books are generally so short that their main points can be grasped easily.
  • People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.
  • Machine language is necessary in any case, as output of many of the software programs I describe.
  • Expressing basic methods like algorithms for sorting and searching in machine language makes it possible to carry out meaningful studies of the effects of cache and RAM size and other hardware characteristics (memory speed, pipelining, multiple issue, lookaside buffers, the size of cache blocks, etc.) when comparing different schemes.
Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur. I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren't the point of my books, the point is rather what you can do in your favorite language. My books focus on timeless truths.

Therefore I will continue to use English as the high-level language in TAOCP, and I will continue to use a low-level language to indicate how machines actually compute. Readers who only want to see algorithms that are already packaged in a plug-in way, using a trendy language, should buy other people's books.
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).
  #84  
Old 07-24-2019, 06:02 PM
Max S. is offline
Guest
 
Join Date: Aug 2017
Location: Florida, USA
Posts: 1,137
Quote:
Originally Posted by Sage Rat View Post
1) 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.
2) Those are long names.
If you are still talking about x86, those are labels and are abandoned during the link pass.

Quote:
Originally Posted by Sage Rat View Post
3) Assembler was abandoned for a reason.
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?

Quote:
Originally Posted by Sage Rat View Post
4) Mathematics has no such hardware restrictions.
Right you are. Programming is the one with hardware restrictions, although these are implementation-specific.

Quote:
Originally Posted by Sage Rat View Post
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.
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:
  • It takes less time to write fewer letters
  • The intended audience generally knows what the single letters mean
  • It is easier to fit on a printed page - journals still publish on letter-size paper, even if electronic
  • It is shorter and therefore easier to see patterns
  • It is easier to drop any preconceived notions about a variable if the name is less descriptive

I'm sure there are other reasons, too.

Quote:
Originally Posted by Sage Rat View Post
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."
Don't be silly.

The command is jmp, not goto.

~Max
  #85  
Old 07-24-2019, 06:34 PM
Max S. is offline
Guest
 
Join Date: Aug 2017
Location: Florida, USA
Posts: 1,137
Quote:
Originally Posted by DPRK View Post
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).
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.

~Max
  #86  
Old 07-24-2019, 09:46 PM
RaftPeople is offline
Guest
 
Join Date: Jan 2003
Location: 7-Eleven
Posts: 6,688
Quote:
Originally Posted by DPRK View Post
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).
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.
  #87  
Old 07-24-2019, 10:23 PM
Melbourne is offline
Guest
 
Join Date: Nov 2009
Posts: 5,189
Quote:
Originally Posted by Settimo View Post
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):
  • 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)
  • expandable/collapsable proof boxes
  • 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
  • callable / invokable summary sheets, with eg main formulas, main theorems, variables (also where they are introduced)
  • 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)
  • maybe some color coding for certain stuff (that doesn't make the eyes bleed; no yellow!)
  • "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)

What's the drawback? It takes more time for the author.
And, according to the MD I know who is studying math, one of the (electronic) textbooks he is studying is written that way.
  #88  
Old 07-24-2019, 10:47 PM
str8cashhomie is offline
Guest
 
Join Date: Jan 2017
Posts: 67
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.

Quote:
Originally Posted by Sage Rat View Post
Hm. Bizarre. The amount of force I get hit with is independent of the current velocity, just how quickly it's changing? Whether a bullet is traveling at 1 m/h or 1000 m/s, it will have the same force so long as it was traveling at an equivalent difference of speed in the previous measurement period?
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.
  #89  
Old 07-24-2019, 10:53 PM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by Max S. View Post
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?
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.

Quote:
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.
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.

Quote:
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.
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:
  • It takes less time to write fewer letters
  • The intended audience generally knows what the single letters mean
  • It is easier to fit on a printed page - journals still publish on letter-size paper, even if electronic
  • It is shorter and therefore easier to see patterns
  • It is easier to drop any preconceived notions about a variable if the name is less descriptive
I will grant that code prints poorly. Otherwise, none of these is compelling in any way.

1) The audience understands - Ergo, you have reduced the audience to those who can understand.
2) 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.
3) 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.

Last edited by Sage Rat; 07-24-2019 at 10:55 PM.
  #90  
Old 07-24-2019, 10:58 PM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by Max S. View Post
Don't be silly.

The command is jmp, not goto.

~Max
I can't come up with a good joke about racism and considering x86 to be the only valid assembler language, but consider it made.
  #91  
Old 07-24-2019, 11:13 PM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by Sage Rat View Post
Ι m(Ι c, Χ** v) {
← 0;
}
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 -27 nor greater than 27 - 1 and a null value.

V is the cartesian product of a sets v0 .. vc - 1 and the whole numbers.

Function m() returns whole values in range -231 nor greater than 231 - 1.

m(V) ≔ ← 0 dx

m() may be extended for further processing of inputs in range c.

Last edited by Sage Rat; 07-24-2019 at 11:15 PM.
  #92  
Old 07-25-2019, 01:01 AM
Indistinguishable is offline
Guest
 
Join Date: Apr 2007
Posts: 10,554
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.
  #93  
Old 07-25-2019, 05:15 AM
PrimalEnvy is offline
Guest
 
Join Date: Aug 2016
Location: Newfoundland
Posts: 129
Quote:
Originally Posted by Indistinguishable View Post
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?
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.
  #94  
Old 07-25-2019, 08:49 AM
Sage Rat's Avatar
Sage Rat is offline
Member
 
Join Date: Mar 2004
Location: Howdy
Posts: 21,664
Quote:
Originally Posted by PrimalEnvy View Post
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.
You've misremembered it and defined angle C using angle C.

real[3] side; // length of side of triangle
angle[3] corner; // corner1 is opposite side1 and so on...

side12 = side22 + side32 + 2 * side2 * side3 * cosine(corner1)

Last edited by Sage Rat; 07-25-2019 at 08:51 AM.
  #95  
Old 07-25-2019, 10:03 AM
DPRK is offline
Guest
 
Join Date: May 2016
Posts: 3,479
Quote:
Originally Posted by Sage Rat View Post
You've misremembered it and defined angle C using angle C.

real[3] side; // length of side of triangle
angle[3] corner; // corner1 is opposite side1 and so on...

side12 = side22 + side32 + 2 * side2 * side3 * cosine(corner1)
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.
  #96  
Old 07-25-2019, 11:16 AM
Max S. is offline
Guest
 
Join Date: Aug 2017
Location: Florida, USA
Posts: 1,137
Quote:
Originally Posted by Sage Rat View Post
And? There's still a thriving saddle-making trade. Does that somehow mean that the car was a bad idea?
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.

Quote:
Originally Posted by Sage Rat View Post
Pointing out that things exist doesn't mean that 'only' things should exist or are in some way preferable.
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.

Quote:
Originally Posted by Sage Rat View Post
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:
Code:
main()
{
    printf("hello, world\n");
}
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:
Code:
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 != '\n')
        s[i++] = c;
    if (c == '\n')
        s[i++] = c;
    s[i] = '\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[i] != '\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.

Quote:
Originally Posted by Sage Rat View Post
1) The audience understands - Ergo, you have reduced the audience to those who can understand.
2) 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.
3) 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.)
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.

~Max
  #97  
Old 07-25-2019, 09:37 PM
Melbourne is offline
Guest
 
Join Date: Nov 2009
Posts: 5,189
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.
  #98  
Old 07-26-2019, 09:24 AM
Max S. is offline
Guest
 
Join Date: Aug 2017
Location: Florida, USA
Posts: 1,137
Quote:
Originally Posted by Melbourne View Post
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.

https://news.ycombinator.com/item?id=1245255
https://www.reddit.com/r/programming...ming_language/
https://stackoverflow.com/questions/...icable#8478069

~Max
  #99  
Old 07-26-2019, 12:13 PM
Indistinguishable is offline
Guest
 
Join Date: Apr 2007
Posts: 10,554
Quote:
Originally Posted by PrimalEnvy View Post
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.
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!)]

Last edited by Indistinguishable; 07-26-2019 at 12:14 PM.
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 04:01 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.

Send questions for Cecil Adams to: cecil@straightdope.com

Send comments about this website to: webmaster@straightdope.com

Terms of Use / Privacy Policy

Advertise on the Straight Dope!
(Your direct line to thousands of the smartest, hippest people on the planet, plus a few total dipsticks.)

Copyright 2018 STM Reader, LLC.

 
Copyright © 2017