In terms of pure mathematics, I’m not sure that this is true - though obviously, that’s not my area of knowledge.
To the extent that I can tell, pure mathematics always deals in diagrams. And while diagrams may well represent things that can’t be displayed in 2D, they are nevertheless simply lines, points, nodes, etc.
Graham’s number was the output of research on cuboids. A cuboid has edges and vertexes, etc.
There is no particular reason that you can’t call your variable for the length of an edge in your hyper cuboid ‘edgeLength’. It may be pure mathematics, but it is nevertheless the edge length of your hypercuboid.
Well I should have put “IME”, but yeah IME most mathematicians write code (and obviously mathlab counts as code)
The main uses are probably: 1. Any time many calculations need to be performed 2. Visualization e.g. in geometry / topology 3. Share datasets with others 4. Run simulations (in applied mathematics)
This is an example of how once a person gets used to one system, they often find it hard to see the benefits of switching to another system.
Objectively-speaking the algebraic system is quicker to both read out, and write down moves. (I also think there’s less chance of confusing moves because every move only mentions one piece. Though that one’s debateable as some may consider it easier to confuse, say, C4 and D4).
Right from the get-go, you’re building on some shaky foundations here:
wax tablets, in particular, are endlessly rewriteable.
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)
For many people, understanding a short symbol is easier than understanding a larger one; a lot of my Chemistry tutoring in the US was spent explaining that [HCO[sub]3[/sub][sup]-[/sup]] can, and in fact for a very popular family of Chemistry problems* is, a variable. In English “a rose is a rose by any other name”; in Spanish llámalo x, “call it x”, has that same meaning of “the essence of things does not change depending on what you call them”, but it is also one of the most basic tools when doing algebra on stuff whose usual symbol is large and clunky. I am very grateful to my Physics and Chemistry HS teachers for the effort they put into making sure that their students knew to write our substitutions at the beginning of a problem, and to revert them explicitly at the end of the same.
That the OP has apparently encountered work by people who didn’t know to apply those rules doesn’t mean the solution is to have to drag large symbols all around the page when calling it x is just a lot more convenient. It’s not about space, it’s about ease.
equilibrium problems, and specifically those based on the carbonate family. Teachers love their bicarbonate, man.
“A few years”? My Dad’s chess books are written like that and they’re dated in the 1950 through the 1970s. I suspect it may be a matter of one of several pre-existing notations becoming more widespread: you had been trained in a different one, but you might actually have been in a minority.
This is not correct. Computer languages, at least the good ones, are lexically scoped so that you can reuse variable names. A well-designed function is short and has no side-effects, so it’s safe (indeed preferable) to use short variables like a, i, n, or whatever.
Meaningful variable name are only important in these cases:
[ol]
[li]Your language is not typed[/li][li]Your language is not lexically scoped (in this case, first try finding another job)[/li][li]You inherited a codebase where the methods/functions are too long, or it isn’t even organized into distinct units.[/li][li]When calling a foreign function, it is helpful (though not required) to use a variable name that hints how it will be used in the called function.[/li][/ol]
Basically… write good code, and this problem isn’t a problem anymore.
To phrase another way, much of the body of mathematics has no application at all, whereas a computer program likely mediates at least one application. So it can be helpful to differentiate context.
but again, as I write above, the solution there is to make your code more math-like (use tight, single-purpose functions with no side effect). Let your function signature explain itself, don’t put this burden on variables or comments (which have been known to lie).
I can’t tell for sure, but you may be confusing “function” and “formula.” In computer programming, a function is something that performs a specific, well-defined calculation for a specific purpose; but that’s not how modern mathematicians use the term “function.”
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?
A good writer of mathematics or anything else should know their audience, and should not use terminology or symbols that a significant portion of that audience would be unfamiliar with, without some sort of explanation or reference. That’s true of any field.
This is absolutely horrible advice. Fortunately, I’ve never encountered a large system where anyone was naive enough to actually do this.
If you’ve decomposed your functions to the extent that you don’t need any meaningful variable names then you’ve decomposed way too far and reduced the readability of your code and thus cost your company money due to the time it takes for others to figure out how it works.
In addition, this just pushes the problem onto the function names. When you have an order of magnitude more names then the need for organization of the names increases significantly and the length of the names increases. It can be challenging to create function names that incorporate the full hierarchy of context.
You’ve also cost your company money due to the overhead of creating hundreds of thousands or millions of functions that didn’t need to exist.
Regarding no comments:
Programming languages are not designed to describe anything about the problem being modeled. While it’s true that good code organization and naming of functions and variables can reduce some of the need for comments, they simply can not eliminate the need for additional information for rapid understanding of the software.
Regarding comments lie:
“comments (which have been known to lie)”
So can function names, class names, table names, etc. Everything can lie, so your solution is to eliminate a valuable tool because some people make mistakes once in a while?
Should we eliminate function names for the same reason?
In 20+ years as a software developer, I have never encountered code that had so many comments as to decrease readibility, nor have I encountered nonsense oft-cited examples like commenting x++ with // increment x
However plenty of times I’ve had to basically reverse-engineer code peppered with single character variables and sod all comments.
Or, to put it another way, if “True Scotsman” programmers always write clear enough methods or functions that meaningful variable names are not required, then I know of no True Scotsman programmers.
(The one exception though might be non-nested loop variables)
This is 100% unsubstantiated opinion. Honestly it seems like you’ve never read or written good code. Good composition results in maximum readability. Readability should arise from the structure of the program, not your choice of verbiage.
Clearly you’ve never heard of namespaces, which are a basic feature of most commercially used programming languages, so we can pretty much discard the rest of your junior critique.
By what reasoning did you determine that thousands of variable names are cheaper than thousands of function names? (Setting aside that it isn’t a 1 for 1 exchange).
This is not exactly true. When programmatic entities are incorrectly named, this will often be flagged/failed by the compiler, or a unit test, or an integration test, or a runtime. In other words there is some penalty for lying and some protection against it… for every entity except for comments.
Dude, dial the heat down a notch. Most of your post boils down to “that’s now how I do it or how I like to do it, and things I don’t like are probably expensive.”
Your appeal-to-ignorance fallacy kind of cancels out your No True Scotsman there.
Anyway, my point is not “never write comments” or “never use good variable names”. I did not suggest that. Rather I suggest that good program structure should be the first choice for self-describing code.
And if that isn’t possible, here are some perfectly good reasons to write comments, and ways to write them so they don’t lie:
[ul]
[li]Explaining the intent of the code. Why did I write this method?[/li][li]Explaining a seemingly nonsense practice. This looks weird/risky. Why did I do that?[/li][li]Signaling a known instability or site of change. This code may break after the year 2038![/li][/ul]
Likewise, here are some good reasons to be very descriptive in variable names:
[ul]
[li]Your language uses global variables or lacks namespacing[/li][li]You are calling a foreign function and you want to signal what you think you’re passing to it.[/li][li]You are defining the parameters of a method signature.[/li][li]Your language doesn’t have types, so your variables need a type hint.[/li][li]Your method body is more than a half-screen long, and you don’t have time to refactor it.[/li][/ul]
Considering above, I would ask we talk about why we make certain choices, and the contexts where they make sense, instead of simply declaring that my preferences are good and cheap, but yours are bad and expensive.
For example, the survival skills you learned in PHP are partially irrelevant in Java and wholly irrelevant in Elixir (not that anything is wrong with PHP or Java, and clearly I’m an Elixir fanboy. Just pointing out that the survival practices are different because the languages are different).
40 years ago I adapted the Jensen/Wirth Zurich Pascal compiler for my dissertation. The structure was very good, but for some reason they used one or two character variable names throughout. It took me two months to document everything. I blame Wirth because his data structures text did the same thing.
Clearly you’ve never heard of namespaces, which are a basic feature of most commercially used programming languages, so we can pretty much discard the rest of your junior critique.
Thousands of function names imply thousands of functions.
That is misspelling, not lying.
As for comments, they are especially useful in giving the context of code, especially for code written to handle corner cases or weirdnesses forced upon you by your environment. Or do you trust in up to date external documentation?
When writing and proving theorems, mathematicians explain what every bit of notation means, aside from universally accepted notation for sets like the integers, rationals, reals, or complex numbers. As DPRK said:
Language like this may be Greek to the average reader, but as others have said, the hard part is the concepts, not the language. The intended audience of people who could make sense of the underlying ideas aren’t going to be slowed down much by the notation.
What did I write to make you think that? I did not mention or imply anything about external documentation. Read my replies above where I explained when comments can be desirable.
Or actually…don’t. I’m done with replies that put words in my mouth or don’t read what I actually posted. However, thank you for being a prime example of one of the biggest problems with comments: people just don’t read.
There is research surrounding this topic, it’s not just opinion.
40 years of experience in a wide variety of languages, OS’s, and problem domains.
The compiler has no idea of the intent of the function and whether the name supports that intent.
The heat is warranted due to how poor the advice was. It’s based on objective evidence from 40 years of experience with large enterprise systems.
Once in awhile I get a lead or a programmer that read some blog somewhere with this type of advice and took it to heart and it takes time to correct their incorrect notions.
It would have been an appeal to ignorance had I claimed that no such programmers exist.
Instead I am simply questioning the merit of your advice, given that in my 20 years experience it would be precisely the wrong advice for every programmer I have worked with.
Then it would seem there’s little to debate. No-one is going to argue against good program structure being of primary importance.
I guess the one remaining thing is that you are still implying that sometimes clear variable naming is beneficial, when my opinion is that it almost always is, and for many of the reasons you list.
Conversely I don’t see any benefit of using single-character names.
, depending whether you were White or Black (algebraic had a single name)