Symbolic vs. Mnemonic Relational Operators: Is "GT" Greater Than ">"? 304
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?"
Wow, a paper about GT (Score:2, Troll)
Re:Wow, a paper about GT (Score:4, Interesting)
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.
Is it really a waste of time? (Score:2)
A computer language, at least so far, is a means for a human to write something in a structured manner that can be turned, eventually, into sequences of instruction execution that do what the human intended.
Clarity -- particularly for the newcomer to a language, but also for creation, debugging and maintainance purposes by those who are relatively expert -- trumps conciseness up to a point. This, I think, is why languages with syntax of similar densities to APL are not popular.
We could say ">", "GT" or "
Re:Is it really a waste of time? (Score:5, Insightful)
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 [php.net].
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.
Re: (Score:3)
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.
Re: (Score:2, Insightful)
I guess we've met this guy [xkcd.com]. Apart from that, personally I'd like to ban the lone "=" operator so it's "==" for comparison, ":=" for assignment with all the other two char operators like != and += intact. So many languages try to be "smart" instead of just making the difference more explicit.
Re: (Score:2)
I'd like to ban the lone "=" operator so it's "==" for comparison, ":=" for assignment with all the other two char operators like != and += intact. So many languages try to be "smart" instead of just making the difference more explicit.
Here's a nickel, son. Go get yourself a proper compiler.
Re: (Score:2)
It seems pointless to make "=" meaningless, and to replace it only with something more difficult to write, while no more visually distinct.
= and == seem to me to be perfectly reasonable, no more visually or conceptually obscure than ":=" and "==", and with the bonus of being easier to write.
C does it right, in my view: comparison is explicit; assignment can be overloaded as
Re:Wow, a paper about GT (Score:5, Informative)
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.
Re: (Score:3)
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.
Re: (Score:2)
Problem with that is C (and by derivation C++ and a number of other languages) allows you to use the value from an assignment as a right hand value. That allows both of these constructs:
x = y = z = 5
x = y == z = 5
In the first line, all 3 variables are assigned the value 5. In the second, "z" is assigned the value 5. 5 is then compared to "y" and the truth of that comparison (0 or 1) is assigned to "x". You can't just use one operator for both assignment and comparison. It fundamentally breaks the langu
Re: (Score:3)
Just because they allow you to do this doesn't make it sensible, good programming or acceptable in any sane code base.
Not even correct. (Score:5, Informative)
Re: (Score:2, Insightful)
That's one of the reasons I find Perl to be an undesirable language to use.
Re:Not even correct. (Score:5, Informative)
I can understand why one might dislike this distinction between string and numeric operators in Perl, but I personally like it a lot.
Perl is an odd hybrid. On the one hand, it for the most part does not distinguish between different scalar data types syntactically (no strict declarations as in C++). This makes it a more casual language that is good for quick scripting within a limited environment (similar to JavaScript), but of course it could lead to confusion later on if a programmer reassigns variables to different data types on the fly. On the other hand, Perl solves potential confusions by using distinct operators for string and numeric operations. This means that (A) it is clear what is being done at any given point, and (B) it simplifies converting between numeric and string data types for on-the-fly operations. This is why Perl is amazing: you can do so much in a single, miniscule line of code, and yet everything you do is very clear and straight-forward in the syntax, however brief it is. Perl is thus capable to some extent of emulating one's flow of consciousness rather than requiring a strict, logical process according to clearly-defined data types. After all, my brain only seems to distinguish between string and numeric data types when I operate upon them (e.g. when I think about the number 2, I can freely flow between adding 3 to it and writing the number out as a word).
Re:Not even correct. (Score:4, Informative)
So you've averaged writing over a hundred lines of perl every day since Larry Wall first shared it?
There's clearly something wrong with the language and/or you, but I'll be polite and avoid suggesting which.
Re: (Score:3)
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".
Of course! (Score:3)
Of course a Gin & Tonic is greater than some symbol
Re:Of course! (Score:4, Funny)
Of course a Gin & Tonic is greater than some symbol
Yes! Cue the blonde joke: "I'll have a Fifteen." bartender: "What?" blonde 'You never heard of a Seven and Seven?"
thanks; try the veal.
Typing versus Reading (Score:3)
Re: (Score:3)
Re: (Score:3)
I had a professor who couldn't touch type, he used hunt and peck. That is obviously suboptimal, but he was able to program fast even with that handicap.
Agreed. Except the shell, editor (Score:3)
> 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 - bre
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I think he's right about the mnemonics being easier to type.
Mnemonics being easier to type is definitely a VERY good reason that FORTRAN used mnemonics. I mean, you try typing > on a 1966 era kyyboard which doesn't have the > symbol. You will find that doing so is exceptionally difficult.
Even F77 was limited to +-*/().,'$:= because they couldn't rely on computers having anything else at all.
Re: (Score:3)
leave it the frick alone (Score:2)
Most languages have used roughly the same operators for at least 40 years. Generations of programmers know > is greater-than. Leave it alone.
Re: (Score:2)
That's before getting into the use of those characters, along with other bracketing characters, in other uses in
Re: (Score:3)
> and 1 (X is bigger / greater than 1 )
Almost everyone could figure it out ... in 3rd grade. If you had a teacher that understood math, they can make anything easy to understand. The problem is, most grade school teachers are VERY poor at basic math. And it shows.
I'm in education, I see this first hand. Teachers who need calculators to do basic math. And we wonder why our kids can't do simple math anymore.
Re:Typing versus Reading (Score:5, Insightful)
Re: (Score:3)
Call me crazy, but I expect a teensy bit more from a graduate of a 4-year university in a math-heavy major, than I do from 4th graders or the general public.
Re:Typing versus Reading (Score:5, Interesting)
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.
Re: (Score:2)
Mnemonics are for people who want to later have to remember which DSLs decided on "ne" and which ones decided on "neq" and hence lose most of the benefit.
The only real advantage to them is on the commandline so you don't have to escape shell syntax. Or when you actually make them do something subtly different (but useful) than the symbolic ones, as in Perl.
mnemonic assumes everyone speaks English (Score:3, Insightful)
Stick to simple mathematical symbols for the basic comparators we've use since elementary school. Shame about the fucking mess with = and ==.
Re:mnemonic assumes everyone speaks English (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
int x = 5;
if(x = 7)
{
foo();
}
This gets caught at compile time because x = 7 evaluates to an int which can't be used as a condition by itself.
The only problem you get is if you have a case where x is a boolean type and you're doing assignment instead of comparison, but you shouldn't need to check (x == true) or (x == false) anyhow as you can just
Re: (Score:2)
TRUTH.
Also, "GT" could mean a lot of different things to a lot of different people, whereas ">" would mean the same thing to all (madmen aside).
In my native language, "Greater Than" ("GT") should become "MMD". Ironically, "Lesser Than", in my native language, would also be shortened to "MMD" (because "Greater" and "Lesser" start with the same letter in my language).
Of course, we could use "MMD" and "MmD" to differentiate, which would work under certain languages but not at all in others. Or stick to the
Re: (Score:2)
Of course, you can type GT and have it show up on Slashdot without weird codes, so that's something.
Re: (Score:2)
X > Y "X is bigger than Y" It is an evaluation not an operation. The alligator wants the bigger one.
The fact that people are confused is because they don't understand what is being asked. "Which one do you want, X amount of chocolate or Y amount of Chocolate? Now, say it to explain it ...." leaving the answer, "I want X because it is bigger/greater than Y"
Re: (Score:2)
Re: (Score:2)
What the poster meant is that on a semantic level, mnemonics symbolize (stand in for) the symbols. For example, we use the symbol == for a comparison operation. We can also define a mnemonic, gt, for that same operation.
However, neither one is the actual comparison - they are both mnemonics (or they are both symbols in the broader sense).for a mathematical operation that takes place when the code is invoked.
A disassembler can convert the binary to individual instructions, such as:
LD AX 14
LD BX CX
CMP AX
Re: (Score:2)
I do think it's worth thinking about which is better, even if the author didn't give very good reasons. It would have been cool if he'd done a study that actually did show one to be preferable (or more likely, which situations each one is preferable).
Re:mnemonic assumes everyone speaks English+ (Score:3)
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
"===" Equival
Blocking and non-blocking substitutions. (Score:3)
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 cons
Are there any non-English languages? (Score:5, Insightful)
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.)
Re: Are there any non-English languages? (Score:2)
Re: (Score:2)
I had a similar first thought as well. There's no reason to increase the mental overhead on people who don't have English as a first language. It's one thing to have functions or classes named in English, since there are already so many of those that it's a matter of memorization anyway, regardless of your native tongue, but it's something else entirely to take mathematical symbols that are well understood across a variety of spoken languages and replace them with something that's English-specific.
Moreover,
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
A bare minimum of English is needed for programming. If, else, switch, case, import and so on are hard to avoid.
I would still argue that > is better than GT though. The reason is that reading the meaning from a symbol comes more natural to the brain than reading letters, which is then turned into a sound/word, which then is turned into a meaning. This mean a symbol like > takes less energy for the brain to read and it becomes easier and faster to read the code. Also using letters for variables and sym
Re: (Score:2)
Come one, you only need to know maybe a hundred English words and no grammar to understand what mnemonics are about. In fact, non-natives may have a slight advantage because their smaller and more specialized vocabulary may reduce the risks of confusion. ...
I am not a native speaker and language was never a problem for understanding mnemonics. If there is a problem, it is in the details : strings or numbers, signed or unsigned, strict or may be equal, precedence rules,
Re: (Score:2)
Re: (Score:2)
Someone with too much time on his hands... (Score:2)
Knowledge of English (Score:5, Insightful)
">" 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.
Re:Knowledge of English (Score:4, Insightful)
Because code review
Re:Knowledge of English (Score:5, Insightful)
I don't know if the world needs even more unreadable code where people are overriding the basic operator names.
Re: (Score:2)
HTML parsers have to be mindful anyway. That's why scripts end with and nothing else (i.e. it's SUPPOSED to ignore any HTML tags within the script as well, in case the SCRIPT wants put push out HTML tags!).
Your crappy parser is not an excuse.
Re: (Score:2)
Fucking Slashdot - was your crappy parser written by one of the Slashdot crowd? There's supposed to be a close script tag in there.
Ignored after the first sentence (Score:5, Interesting)
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.
Re: (Score:3)
Dynamically typed languages should somehow allow explicit type comparing. Perl has the right idea, but it's too easy to forget to use the right one, especially if you work with other languages.
I'm starting to lean toward functions like str_gt(), num_gt(), etc. (or str_greaterthan();).
Another option is something like: "str_cmp(a, '>', b)" and "num_cmp(a, '>', b)". I often make my own utility functions for such because the built in ones don't fit my needs. For example, I often compare strings first by
Re:Ignored after the first sentence (Score:4, Informative)
Perl has the right idea, but it's too easy to forget to use the right one, especially if you work with other languages.
Actually it is quite easy to remember Perl's usage... The operator 'gt' uses strings and is used for a string comparison. The ">" is a math symbol and used for numeric comparison.
Logical Operator (Score:2)
To me it a logical operation is part of an equation and symbols make much more sense than abbreviations. Mixing symbols and mnemonics just confuses things.
= gt = & = lt = (Score:2)
The problem with is it could be a forwards arrow or 'greater than or equal to'
It means different things amongst the languages most people use most of the time.
Overloaded terms suck. Let's not do that.
Re: (Score:2)
That post got mangled beyond recognition by the slashdots. Please insert right and left angle brackets where it makes sense.
You use the symbolic (Score:2)
You use the symbolic. They are concise, they help with the processing in the meat brain (if writing words was better for humans parsing formula, then mathematicians would never have resorted to formula), and they don't need to be translated when going to a language where Greater Than doesn't abbreviate to GT.
The problem is using operators for other things (Score:2)
It's one thing to use ">" for "less than". It's a whole nuther thing to use it for things like bit shift ">>" or dereference "->" And then there's the various uses of "+" and worst of all "=" vs "==".
I'm firmly convinced someone will write a paper on "C Syntax Considered Harmful," and symbol misuse is one aspect of C that causes bugs.
Re:The problem is using operators for other things (Score:5, Insightful)
It's one thing to use ">" for "less than".
That would be almost bound to cause confusion.
Operator overloading (Score:2)
I've seen that sort of operator overloading. For some reason it made sense at the time, though I can't remember why.
Either math or real language (Score:2)
Mnemonics like GT or LT make no sense unless you program in assembly.
If you can enhance languages like C++ to accept them, then use 'greater' etc.
I'm working on my own language, too. Close to programming languages but easy to read and easy to type on tablets. Sure, I could craft a full IDE and habe a custom keyboard.
However the constraints that are the reason that some languages use -eq or .eq. as comparission operators are long gone.
What I don't get e.g. why people insist to use def for both variables and
Re: (Score:2)
What I don't get e.g. why people insist to use def for both variables and functions ... other languages use func, var, val, let.
Because in some languages a function is just another type of data that you can process, modify or create with other functions. It's when you call it, not when you define it, where the rubber meets the road.
Re: (Score:2)
Exactly, and a 'definition' is already a higher level concept. ;)
For beginners it is much easier to grasp that the are 'making' a variable with the var keyword and are 'making' a function with the 'fun' keyword.
Calling is a different matter, some languages actually use the call keyword for that
And please: can you tell us laymen the difference between a 'declaration' and a 'definition'? While you are about the nitpicking right now?
My point simply is: there is no need anymore to have esoteric language concept
Reasonable mixture (Score:2)
A reasonable mixture of both conventions should be used, and it's a bad idea to have synonyms for primitive operations. Readability is more important than being able to type code fast.
A good language defines a minimal set of primitive operations and allows the user to define the rest, including infix, postfix, and prefix operators, so it's not clear to me what the problem is.
It's all about vocabularies (Score:2)
Depends upon context ... (Score:2)
When the symbols are in common use and are being used in the conventional sense (such as >), then go with the symbol.
Examples:
C: a > b, common use and used by convention. Should be used.
LISP: (> a b), common use but not common convention. Probably should not have been used.
ASM: J>, not common use nor common convention. Thankfully it wasn't.
It should also be noted that mnemonics aren't an ideal solution either. Mnemonics relies upon the reader understanding the context since any given mnemoni
It's all squiggles (Score:4, Interesting)
It's all squiggles on the screen that I have to learn to interpret in the correct context.
Re: (Score:3)
It's all squiggles on the screen that I have to learn to interpret in the correct context.
This is true. All letters are symbols, and all symbols require a context in order to interpret. Somebody above pointed out that > is universally understood in mathematics, and thus its universality seems to make it preferable to GT, which is based on English. But this can be misleading. In the long run, > is just as arbitrary as GT, and although the symbol is widely used in mathematics, that is no guarantee that it will retain a clear meaning forever. A context will always be necessary, and although m
Re: (Score:3)
The strength of C++, for example, is that you can define your own operators and how they operate upon particular data structures
IMO the weakness of C++ is that you can define how the provided operators work on custom types but you can't create new ones.
The result is that the set of provided operators gets overloaded to have very different meanings.
A vote for symbols... (Score:2)
I started off programming in Algol in the sixties. I have used symbols and abbreviations.
Abbreviations can give you clashes with variable names. You normally learn what to avoid, but it is easy to have integers i, j, k, and floats if, jf, and kf, and not notice what you have.
That being said, it is a shame we don't have the right symbols on your keyboards. I would like... - Separate single symbols for assignment (:=) equality (==) and perhaps identity, or deep equality - The set cup and cap symbols for
Fortran's use of GT (Score:2)
Back when Fortran came out, keyboards weren't standardized yet. Also, some systems used variations of 7-bit or even non-ASCII encodings like EBCDIC. The > symbol wasn't guaranteed to be present on a given keyboard or even in the codepage. Using GT was out of necessity, no other reason, because letters were guaranteed to be on every keyboard and in every codepage.
Later languages (such as C and BASIC) were criticized for their lack of portability, but eventually because of them, ASCII became a standard.
Re: (Score:2)
Back when Fortran came out, keyboards weren't standardized yet. Also, some systems used variations of 7-bit or even non-ASCII encodings like EBCDIC. ...
Uhh, not quite. Back when Fortran was introduced in 1957 and when comparison operators were introduced in Fortran IV in 1962, pretty much everyone was entering programs on punched cards, mostly using the IBM 026 keypunch machine which did not have the greater than and less than symbols. In fact a special 026 "scientific character set" was required to show parentheses or equal sign on the keyboard or to print them on the cards. While each computer model tended to have its own internal character code, the pun
Slow news day or something? (Score:2)
What this is: (Score:2)
This is weapons grade stupid. This ranks up there with "let's talk about the best editor". People who write articles like this aren't actually attempting to make a point we should care about. They're talking for the sake of hearing themselves talk.
iso646 (Score:2)
Personally, ... (Score:2)
It's not a matter of preference (Score:4, Informative)
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!
Re:Do anything other than what Perl did (Score:4, Informative)
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.
Re: (Score:2)
^ 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.)
Re:Do anything other than what Perl did (Score:5, Funny)
^ This
Not This?
Re: (Score:2)
Re: (Score:2)
As perl was envisioned as a replacement for shell scripts: not consistent at all. ;)
In sh/ksh/bash == and != are string comparisons, numeric ones are -eq and -ne etc.
Re: (Score:2)
Re: (Score:2)
The more complex and TIMTOWDIsh a language is, the more potential work you have to do to create parsers/IDEs for it.
Re: (Score:3)
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.
Re: (Score:2)
A symbology that requires one to read in a different direction based on the symbol would be extremely retarded and infinitely stupid.
Re: (Score:2)
why? COBOL has accepted > = since at least the early 70's.
COBOL got something else right as well, "=" is totally unambiguous - it takes MOVE FIELD1 TO FIELD2 to assign something.
Re: (Score:3)
Re: (Score:2)