Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

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?"
This discussion has been archived. No new comments can be posted.

Symbolic vs. Mnemonic Relational Operators: Is "GT" Greater Than ">"?

Comments Filter:
  • Guess he had spare time on his hands
    • by prunus.avium ( 4301083 ) on Tuesday November 10, 2015 @12:54PM (#50901785)

      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.

      • 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 "

        • by nmb3000 ( 741169 ) <> on Tuesday November 10, 2015 @04:22PM (#50903897) Journal

          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.

          • It's the same reason && is better than "AND" in C syntax derivatives.

            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)

      by Kjella ( 173770 )

      I guess we've met this guy []. 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.

      • 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.

      • by fyngyrz ( 762201 )

        ban the lone "=" operator so it's "==" for comparison, ":=" for assignment with all the other two char operators like != and += intact

        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

        • by grimmjeeper ( 2301232 ) on Tuesday November 10, 2015 @02:43PM (#50902935) Homepage

          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.

    • Not even correct. (Score:5, Informative)

      by whoever57 ( 658626 ) on Tuesday November 10, 2015 @01:47PM (#50902387) Journal
      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.
      • Re: (Score:2, Insightful)

        by fyngyrz ( 762201 )

        That's one of the reasons I find Perl to be an undesirable language to use.

        • by azcoyote ( 1101073 ) on Tuesday November 10, 2015 @03:48PM (#50903509)

          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).

    • 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".

  • by i.r.id10t ( 595143 ) on Tuesday November 10, 2015 @12:42PM (#50901611)

    Of course a Gin & Tonic is greater than some symbol

  • by szczys ( 3402149 ) on Tuesday November 10, 2015 @12:44PM (#50901637)
    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.
    • by szczys ( 3402149 )
      Just submitted this comment, but not that I think about it. If you want these to be easier to type you should set up your IDE to auto-replace the mnemonics. Type GT(space) and it gets replaces with '>'.
      • The way I look at it, typing speed doesn't really matter (for programming). The bottleneck for my typing speed isn't how fast I type, it's how fast I think. In bad cases, it can take a couple weeks to write ten lines of code.

        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.
        • > 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

          • My main point was that gt and > is probably not going to make much difference either way when it comes to programming speed.
      • Just do an #include with the right header file and you can use mnemonics to your heart's content. Wrote my own before discovering that there was already an existing one.
    • 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.

      • That's the reason early C had trigraphs. So that you could get the job done on old mainframes that didn't have all of the symbols used by the language.
    • Most languages have used roughly the same operators for at least 40 years. Generations of programmers know > is greater-than. Leave it alone.

  • by Anonymous Coward on Tuesday November 10, 2015 @12:44PM (#50901643)

    Stick to simple mathematical symbols for the basic comparators we've use since elementary school. Shame about the fucking mess with = and ==.

    • by Alain Williams ( 2972 ) <> on Tuesday November 10, 2015 @12:51PM (#50901735) Homepage

      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.

      • That's one of my favorite "quirks" of AutoHotkey -- while it does allow usage of a sole "=", assignment can be done with ':=' and comparison with '=='.
      • It's less of an issue for the newer high level languages that are either strongly typed or don't implicitly treat numbers like a boolean. for example:

        int x = 5;
        if(x = 7)

        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
    • 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

    • Mnemonics are symbols too. There's no reason to believe that GT is better than > just because we can pronounce it. That is the primary advantage, right? We see it and we automatically know how to pronounce it. It's still a symbol.

      Of course, you can type GT and have it show up on Slashdot without weird codes, so that's something.
      • 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"

        • I'm pretty sure you had an interesting point in there, but I read your post three times and I'm not really sure what you were saying.
          • 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

            • Nice post.

              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).
    • 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

  • by xxxJonBoyxxx ( 565205 ) on Tuesday November 10, 2015 @12:46PM (#50901667)

    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.)

    • No. There isn't any. Why asking?
    • 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.


      • by Xolotl ( 675282 )
        Agreed. The symbols are easier because every child learns them in primary school maths class. The mnemonics are a relic from a time when the character encoding on the IBM 704 didn't have the > and < symbols, there is no rational reason for using them today.
        • The mnemonics are a "relic" of assembler. Has nothing to do with keyboards missing a symbol or three. GT, LT, EQ, are all assembler mnemonics.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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

    • by GuB-42 ( 2483988 )

      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, ...

    • That's like trying to remember whether P or V is the operator to increment a semaphore.......
    • Just make an include file with macros that expand from the mnemonics you would use in your language to the mnemonics in the base language. CMP (comparer) for ==, etc. Problem solved.
  • Really? This guy wasted time and electrons on this?
  • by ledow ( 319597 ) on Tuesday November 10, 2015 @12:54PM (#50901779) Homepage

    ">" 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.

  • by OverlordQ ( 264228 ) on Tuesday November 10, 2015 @12:55PM (#50901793) Journal

    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.

    • by Tablizer ( 95088 )

      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

  • 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.

  • 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.

    • That post got mangled beyond recognition by the slashdots. Please insert right and left angle brackets where it makes sense.

  • 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.

  • 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.

  • 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

    • 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.

      • 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

  • 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.

  • When the symbols are in common use and are being used in the conventional sense (such as >), then go with the symbol.

    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)

    by OrangeTide ( 124937 ) on Tuesday November 10, 2015 @01:19PM (#50902047) Homepage Journal

    It's all squiggles on the screen that I have to learn to interpret in the correct context.

    • 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

      • 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.

  • 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

  • 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.

    • 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

  • 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.

  • In C I've been a fan of iso646(.h) ever since its proposal: it replaces ||, && and other boolean operators by 'or', 'and' and more readable things like xor.
  • ... I welcome our operator overloads.

  • by jdavidb ( 449077 ) on Tuesday November 10, 2015 @04:08PM (#50903727) Homepage Journal

    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!

An elephant is a mouse with an operating system.