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?"
Of course a Gin & Tonic is greater than some symbol
Don't blame me, I voted for Kodos
I think he's right about the mnemonics being easier to type. They're generally on dominant fingers and you use letters constantly (not so much with pipe, ampersand, great and less than). That being said, I do think the capitalization should be saved for constants, and scanning code with your eyes proves the symbology easier to pick out. Symbols are better.
Stick to simple mathematical symbols for the basic comparators we've use since elementary school. Shame about the fucking mess with = and ==.
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.)
">" 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. They are NOT doing the same thing. You are used to operators being overloaded to do very different things depending on context. Now, Perl does awful things with overloading in lots of other places but in this one place I think it gets it right. (I also think having a dedicated string concatenation operator is the way to do, not overloading + for that purpose.)
It's all squiggles on the screen that I have to learn to interpret in the correct context.
“Common sense is not so common.” — Voltaire
^ This
Not This?
It's one thing to use ">" for "less than".
That would be almost bound to cause confusion.
Shame about the fucking mess with = and ==.
When I did a "desk language" (a notation for writing code on paper notes, which might have had a compiler written for it later), about the time C was being developed (but before I had access to it), one of the things I did was carefully avoid items like that. One thing I did was ban the bare equal sign.
":=" Replacement (also: like C, unary ops had before and after replacement forms - by adding : the same way C adds =, i.e. ":+" and "+:"
"==" Equality
"===" Equivalence (Two variables are aliases for the same storage. Think "union" but as a separate "put these two things in the same storage / use this symbol (perhaps as a different type) for the same bits as that one" declaration.)
I also had the logical and bitwise operators swapped from the way C did it - because "||", "&&", etc. are mnemonic for a string of bits. (This proved to be the biggest stumbling block when I started coding in C.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
> In bad cases, it can take a couple weeks to write ten lines of code
Absolutely agreed. And my ten (or 100) lines do the same task that someone else's 3,500 lines did, and do it more elegantly, because I'm using meta-programming.
On the other hand, at the shell, it's helpful if the typing is fast enough that it doesn't effect my train of thought, which can be fast for tasks I know. You mentioned hunt and peck. That ends up being think, stop, hunt, peck, stop, think, stop, hunt, peck, think, stop - breaking one's train of thought. There's a qualitative difference when you're just thinking and the typing takes place automatically, in another mental "thread".
A symbology that requires one to read in a different direction based on the symbol would be extremely retarded and infinitely stupid.
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 did too, but I was thinking the car, not the video game.
What Perl did was definitely an improvement over /bin/sh where the nmemonic ( ex: -gt ) works on integers while the symbolic ( > ) works on strings ...
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.
relatively recent scripting languages like Perl ... Functionally, the operators are equivalent, so which ones you use is largely a matter of personal preference
That is not the case in Perl at all! In Perl, operators like gt and lt are for string comparisons, and operators like are for numeric comparisons. Since in Perl you can conveniently transmute numbers intro strings and vice versa, which operator you use can make a whole lot of difference!
Secession is the right of all sentient beings.
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
/)
Why do those languages that use GT also use "+" instead of PLUS? a lot of times the reasons aren't about having words instead of symbols, but other pragmatic reasons. There were limitations on early punch card formats, the relevant symbols just may not have existed. IBM Model 026 keypunch did not support . And once you've got "EQ" to distinguish from "=" then it's much easier to use "GT" or "LT".
Just because they allow you to do this doesn't make it sensible, good programming or acceptable in any sane code base.
I'd argue that the 'punctuation gone awry' view of Perl is largely because it was one of the first languages to fully embed regular expressions. While it has a fair number of different punctuation operators on it's own, nearly all are shared by other languages, and most of the rest are because the syntax has to differentiate between different types of variable operations, where more statically typed languages can let the types determine that.
'Sensible' is a curse word.
That may have been true 20 years ago but modern optimizing compilers will generate the same output whether you embed your assignment in the conditional or do it separately.
For completeness sake := is a blocking assignment. Meaning that the next instruction is not executed until the assignment is completed.
You also want a non-blocking assignment. The actual assignment is delayed (and may be overridden in following non-blocking assignments).
Had that: "=:", as with "+:" vs. ":+", etc. Like C's equal-sign-concatinated-with-unary-op semantics, the side the colon is on tells you whether the store occurs before or after the whatever.
Equal sign in my language COULD have been considered a unary do-nothing/"make a local copy" operator (i.e. "foo", "= foo", "= = foo" etc. are all the same thing - except that all but the first might not be acceptable as the target of an assignment, or might result in the store being discarded) - except that, as a special case, a single equal sign was explicitly forbidden to stand alone in an expression.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Given that C has shorthands like ++, I've always wondered why K&R chose && for logical-and and & for bitwise-and. If it were the other way around, you'd save having to write the second & most of the time since one tends to write far more logical-and expressions than bitwise-and expressions.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.