Slashdot Mirror
Symbolic vs. Mnemonic Relational Operators: Is "GT" Greater Than ">"?
theodp writes: "Mnemonic operators," writes SAS's Rick Wicklin as he weighs the pros-and-cons of Symbolic Versus Mnemonic Logical Operators, "tend to appear in older languages like FORTRAN, whereas symbolic operators are common in more recent languages like C/C++, although some relatively recent scripting languages like Perl, PHP, and Windows PowerShell also support mnemonic operators. SAS software has supported both operators in the DATA step since the very earliest days, but the SAS/IML language, which is more mathematically oriented, supports only the symbolic operators. Functionally, the operators are equivalent, so which ones you use is largely a matter of personal preference. Since consistency and standards are essential when writing computer programming, which operators should you choose?"
Are there any non-English languages or anyone using the language for whom English is a challenge? If there are, the use of symbols would seem to be preferred over remembering what the first letters of "plus que" are in English. (FTW.)
I sometimes wonder how many zillions hours of programmer debugging time would have been saved if K&R had used ':=' for assignment (like Pascal) rather than '=' ? The number of times people have assigned rather than compared is huge.
">" is universally understood in mathematics
"GT" relies on a knowledge of English, and what it stands for, and thus what it means.
But the bigger question - WHY does any language created nowadays have hard-coded operator names? If you prefer >, why not just use that and make it equivalent to GT in whatever default settings you provide? Why are you constrained to the choice of operators given to you and the mnemonics they choose to use?
However, arguing over it is pointless. Change if it you can, otherwise it doesn't matter. If you can change it, or overload it, or rename it, or macro-ise it as you like, than it doesn't matter either.
We're on /.. By definition we're all wasting time....usually instead of working.
That being said, this raises some interesting questions about how our brains parse the languages. Would a mnemonic like GT be simpler to parse than >.
Of course, I think this brings up the question of first language. Someone with English and the Latin alphabet may find the mnemonics easier but someone for whom the Latin alphabet is not their primary alphabet might handle the operators better.
They unfortunately used perl as an example. While yes Perl does have both gt and > one is a string comparison and the other is a numerical comparison.
Your hair look like poop, Bob! - Wanker.
In Perl, where there are both operators (e.g. gt and >), the textual one (gt) does a string comparison, while the mathematical one (>) does a numeric comparison, fairly consistently.
^ This
Not This?
It's one thing to use ">" for "less than".
That would be almost bound to cause confusion.
The comparison operators > and < have been in use for four hundred years and are (or should have been) learned in primary school. They also work in any (human) language, not just in English, and map directly to what is used in mathematics. No one should be confused by them.
He includes Perl as a language that has both symbolic and mnemonic operators, and says that functionally they are equivalent, but this isn't really correct. In Perl, for example, "==" is not the same as "eq": one is a numeric comparison, the other is a string comparison and for consistent results the correct operator must be used.
The real "Libtards" are the Libertarians!
I would agree with you except for the horrendous number of hours wasted tracking down places where a single equal was used in place of a double. While lexical analysis tools can catch it, and coding standards (like putting the constant/literal value on the LHS) will help, it's still an unnecessarily wide trap that catches too many people.
There is little real benefit to allowing an assignment to be used as a member of an encompassing expression. In fact, that "feature" only promotes overly complex statements that are harder to read and debug. And with optimizing compilers being so good these days, there's no reason not to break a statement into smaller, more readable pieces.
We could say ">", "GT" or "gt", or perhaps even "greater than."
I disagree. I believe > is easier to parse while reading code since it separates it from identifiers, control statements, constants, numbers, and other keywords. It's the same reason && is better than "AND" in C syntax derivatives.
I'd be quite pleased with a language that understood all three to be the same thing, with similar broad expression capabilities for everything else as well.
Please, no. Syntactic sugar is one thing but creating multiple equivalent ways to express the same thing is just a readability, support, and maintenance nightmare.
explicit and English-like for the newcomer.
Which is how we got COBOL. It turned out that just making source code use lots (and lots) of English words isn't enough to allow laymen to understand it or make changes, so all you end up with is a language that programmers find exhausting to read and annoying to write.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
On the other hand, students and people in-general have gotten > and < confused for a long time.
Many decades ago, my first grade teacher explained that these symbols are like alligators: They choose to chomp on the bigger meal. I've never been confused on these symbols since that day.