Synonyms for operators

Question

In the case of a newly designed functional language, consider e.g. the not equals operator, spelled /= as is common among functional languages.

Of course this operator is also known as != in C family languages, and <> in SQL et al. It would be easy to make the parser accept these as synonyms, in the hope of cutting down on the number of things for someone not very familiar with the language to trip over. But on balance is this a useful thing to do, or would it just add more confusion than it's worth?

Most mainstream languages don't provide synonyms, probably on the basis that they're designed for programmers who are familiar with the syntax.

But what if you're designing a scripting language, for scenarios in which many users will not be very familiar with it, and may be specialists in something other than programming? Does that tip the balance in favor of providing synonyms to make things easier for newbies?

Answer 1

I believe that when learning a language, the biggest issue is not learning the operators. This is (usually) only a fairly small part of the syntax, which in itself is the smaller part of the whole task. Most competent programmers can write syntactically correct code in a new language after a couple of hours or days. However, the more difficult part is to understand and experience the inner logic of the language, to be able to produce elegant and simple solutions, to use the language constructs the way they were meant to, rather than abusing the language by trying to make it work like another, more familiar one.

And having many (any) imaginable versions of operators in a language has drawbacks too:

• it makes the grammar more complex, thus making the task of compiler / interpreter writers more difficult (which means they will have less time to develop new features for us),
• the same operator symbol may mean different things in different languages, e.g. your example /= would mean "divide and assign" to a programmer grown up on the C family,
• using different notations to mean the same thing makes programs more difficult to read, and consequently, to maintain. One's brain just needs to use some extra capacity to map between those different representations (and a little extra work many times over can add up to significant amounts...), so less capacity remains for the really important stuff.

Answer 2

I have pondered much the same thing in the past. While learning Haskell, I simply could not remember that /= didn't mean "divide by and assign back to". But, you make the mistake... compile, curse the language, recompile, rinse, repeat, until... suddenly, one day, you aren't cursing the compiler anymore - or making the mistake. Now, I only get confused when I've been working in C all day.

In the end, if your language FORCES the programmer to do things a certain way, then that's how they will do it - and if it means that users curse your name while they're learning, then I would humbly submit that this is better than those users cursing the names of everyone they're working with, while their in the room with them, because they all used different operators for their code. Talk about a lousy code review.

Answer 3

Pick one and stick with it. There are a number of things one has to get used to when switching languages. Compared to the other things you will need to deal with, this is one of the smaller ones. Having synonyms will just lead to confusion when two people normally use different symbols but end up on the same project. It is easier to change to knowing X means Y rather than being able to use my normal Y, but remembering that X and Z could also be used in it's place.