Why does the assignment operator assign to the left-hand side?

Question

I began teaching a friend programming just recently (we're using Python), and when we began discussing variable creation and the assignment operator, she asked why the value on the right is assigned to the name on the left, and not vice-versa.

I had not thought about it too much before, because it seemed natural to me, but she said that left-to-right seemed more natural to her, since that's how most of us read natural languages.

I thought about it, and concluded that it makes code much easier to read, since the names that are assigned to (which the programmer will need to reuse) are easily visible, aligned on the left.

aligned = 2
on = 'foo' + 'bar' + 'foobar'
the = 5.0 / 2
left = 2 + 5

As opposed to:

2 = aligned 
'foo' + 'bar' + 'foobar' = on
5.0 / 2 = the 
2 + 5 = right 

# What were the names again...?

Now I wonder if there are other reasons as well for this standard. Is there a history behind it? Or is there some technical reason why this is a good option (I don't know much about compilers)? And are there any programming languages that assign to the right side?

Answer 1

Ditto @paxdiablo. The early programming languages were written by mathematicians--actually all of them were. In mathematics, by her own principle--reading left to right-- it makes sense in the way it works.

x = 2y - 4.

In mathematics, you would say this: Let x be equal to 2y -4.

Also, even in algebra you do this. When you solve an equation for a variable, you isolate the variable you are solving for to the left side. i.e. y = mx + b;

Furthermore, once an entire family of languages-- such as the C family-- has a certain syntax, it is more costly to change.

Answer 2

BASIC, one of the earliest computer languages had the "proper" form of:

10 LET AREA = HEIGHT * WIDTH

which matches the mathematical mindset of specifying a variable, like "Let H be the height of the object".

COBOL was also similar with its COMPUTE statement. As with many ways of doing things, it may have simply been an arbitrary decision that was carried forward through many languages.

Answer 3

Actually, there is a programming language that assigns to the right side: TI-BASIC! Not just that, but it also doesn't use '=' as the assignment operator, but rather uses an arrow known as the "STO" operator.

examples:

5→A
(A + 3)→B
(A - B)→C

In the above example, three variables are being declared and given values. A would be 5, B would be 8, and C would be -3. The first declaration/assignment can be read 'store 5 as A'.

As to why TI-BASIC uses such a system for assignment, I attribute it to being because it is a programming language for a calculator. The "STO" operator on TI calculators was most often used in normal calculator operations after a number was calculated. If it was a number the user wanted to remember, they would hit the "STO" button, and the caclulator would prompt them for a name (automatically engaging the alpha lock so that keystrokes produced letters instead of numbers):

Sin(7 + Cos(3))
                    -.26979276
Ans→{variable name}
                    -.26979276

and the user could name the variable whatever they chose. Having to turn on alpha lock, type the name, then press "STO", and hitting the "Ans" key would have been far too cumbersome for normal operations. Since all calculator functions are available in TI-BASIC, no other assignment operators were added as "STO" performed the same task, albeit backwards when compared to most other languages.

(Anecdote: TI-BASIC was one of the first languages I learned, so when I when I was first learning Java in college I felt as though assigning to the LEFT was unusual and 'backwards'!)

Answer 4

Heuristic 1: When faced with more than one possible way of doing something while designing a language, pick the most common, most intuitive one, or else you will end up with Perl+.

Now, how is it more natural (at least to an English speaker)? Let's look at how we write/say things in English:

Steven is now 10 years old (as opposed to 10 years old Steven now is). I weigh more than 190 pounds (as opposed to more than 190 pounds I weigh).

In code:

steven = 10
i > 190

The following also sounds more natural:

"If Mary is 18 yo, then she can have a candy". "If I am younger than 21 yo, then I will ask my brother to by me tequila".

if (mary == 18) { ... }
if (i < 21) { ... }

than:

"If 18 yo Mary is ..." "If 21 is greater than my age ... "

Now the code:

if (18 == mary) { ... }
if (21 > i) { ... }

Note that this is not natural to either programmers nor English speakers. The sentences sound like yoda-speak, and the code is nicknamed yoda-conditions. These might be helpful in C++, but I am sure most people would agree: if a compiler could do the heavy lifting and alleviate the need for yoda-conditions, life would be a bit easier.

Of course, one could get used to anything. For examples, number 81 is written as:

Eighty One (English) Eighty and one (Spanish) One and Eighty (German).

Finally, there are 4! = 24 valid ways of saying "green apple lies on table" in Russian - the order (almost) does not matter, except that 'on' must come together with 'table'. So, if you are a native Russian speaker (for example), then you might not care whether one writes a = 10 or 10 = a because both seem equally natural.

While linguistics is a fascinating subject, I never formally studied it and do not know that many languages. Hopefully I have provided enough counter-examples though.

Answer 5

It started with FORTRAN in the 1950s. Where FORTRAN was an abbreviation of FORmula TRANslation -- the formulas in question being simple algebraic equations which by convention always assign to the left.

Its near contemporary COBOL on the other hand was meant to be English-like and assigned to the right (mostly!).

MOVE 1 TO COUNTER.
ADD +1 TO LINE-CNT.
MULTIPLY QTY BY PRICE GIVING ITEM-PRICE.

Answer 6

Well, as @diceguyd30 pointed out, there's both notations.

• <Identifier> = <Value> means "let Identifier be Value". Or to expand that: Define (or redefine) the variable Identifier to Value.
• <Value> -> <Identifier> means "store Value to Identifier". Or to expand that: Put Value into the location designated by Identifier.

Of course, generally speaking the Identifier may in fact be any L-value.

The first approach honors the abstract concept of variables, the second approach is more about actual storage.

Note that the first approach is also common in languages, that do not have assignments. Also note, that variable definition and assignment are relatively close <Type> <Identifier> = <Value> vs. <Identifier> = <Value>.

Answer 7

As has already been mentioned, pretty well all the early computer languages worked that way. E.g. FORTRAN, which came along many years before BASIC.

It actually makes a great deal of sense to have the assigned variable on the left of the assignment expression. In some languages, you might have several different overloaded routines with the SAME NAME, returning different types of result. By letting the compiler see the type of the assigned variable first, it knows which overloaded routine to call, or what implicit cast to generate when converting from (e.g.) an integer to a float. That's a bit of a simplistic explanation, but hopefully you get the idea.

Answer 8

It could be a remnant of early parsing algorithms. Remember that LR parsing was only invented in 1965, and it could well be that LL parsers had troubles (within the time and space limitations of the machines at the time) going the other way around. Consider:

identifier = function();
function();

The two are clearly disambiguated from the second token. On the other hand,

function() = identifier;
function();

Not fun. This gets worse when you start nesting assignment expressions.

function(prev_identifier = expression) = identifier;
function(prev_identifier = expression);

Of course, easier to disambiguate for machines also means easier to disambiguate for humans. Another easy example would be searching for the initialization of any given identifier.

identifier1 = expressionOfAnArbitraryLength;
identifier2 = expressionOfAReallyReallyReallyArbitraryLength;
identifier3 = expression;
identifier4 = AlongLineExpressionWithAFunctionCallWithAssignment(
    identifier = expr);

Easy, just look up the left side. Right side, on the other hand

expressionOfAnArbitraryLength = identifier1;
expressionOfAReallyReallyReallyArbitraryLength = identifier2;
expression = identifier3;
AlongLineExpressionWithAFunctionCallWithAssignment(expr = identifier
    ) = identifier4;

Especially when you can't grep punch cards, it's much harder to find the identifier you want.

Answer 9

Asssembly languages have the destination as part of the left-hand opcode. Higher level languages tended to follow the conventions of the predecessor languages.

When you see = (or := for Pascalish dialects), you could pronounce those as is assigned the value, then the left-to-right nature will make sense (because we also read left-to-right in most languages). Since programming languages were predominantly developed by folks who read left-to-right, the conventions stuck.

It is a type of path dependence. I suppose if computer programming was invented by people who spoke Hebrew or Arabic (or some other right-to-left language), then I suspect we'd be putting the destination on the right.

Answer 10

For what it's worth, most statements in COBOL read from left to right, so the two operands were named first, and the destination last, like: multiply salary by rate giving tax.

I won't however, suggest that your student might prefer COBOL, for fear that I'd be (quite rightly) flagged for making such a low, uncouth, tasteless comment! :-)

Answer 11

she said that left-to-right seemed more natural to her, since that's how most of us read natural languages.

I think this is a mistake. On the one hand, you can say "assign 10 to x" or "move 10 to x". On the other hand, you can say "set x to 10" or "x becomes 10".

In other words, depending on your choice of verb, the assigned-to variable may or may not be the subject, and may or may not be on the left. So "what is natural" just depends entirely on your habitual choice of wording to represent assignment.

Answer 12

In pseudocode the assignment operator is very commonly written on the right. For example

2*sqrt(x)/(3+y) -> z

In Casio calculators, even non-programmable variants, the assignment variable is also displayed on the right

A+2B → C

In Forth the variable is on the right, too

expression variable !

In x86, Intel syntax has the destination on the left, but GAS syntax reverses the order, making some confusion to many people, especially on instructions regarding parameters' order like subtraction or comparisons. These instructions are the same in 2 different dialects

mov rax, rbx    ; Intel syntax
movq %rbx, %rax ; GAS syntax

They both move the value in rbx to rax. No other assembly languages I know write the destination on the right like GAS.

Some platforms put the expression on the left and the variable on the right:

MOVE expression TO variable      COBOL
expression → variable            TI-BASIC, Casio BASIC
expression -> variable           BETA, R
put expression into variable     LiveCode

https://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Notation

Most languages assign the value to the left, one of the reasons being easy to align the operators, easier to read and recognize the variable, as the assignment operators and variables' positions will not vary wildly in the lines, and it's easier to read as "let variable be some value".

However some people prefer to say "move value x to y" and write the variable on the right.

Answer 13

I think it follows a logical way of thinking.
There has to be a box (variable) first, then you put an object (value) inside it.
You don't put the object in the air and then put a box around it.