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

Comments

Re:Do anything other than what Perl did

[Anonymous Coward]

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.

Not even correct.

[whoever57]

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:Not even correct.

[azcoyote]

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:Wow, a paper about GT

[grimmjeeper]

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.