Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Aug 3 '11 at 22:19

This question came from our site for professional and enthusiast programmers.

11  
R can assign to the right-hand side (value -> variable). –  You Aug 3 '11 at 22:06
    
Perhaps this is due to bad variable names? How about 'numAligned is 2` and 'chickensLeft is 2+5'? –  Job Aug 4 '11 at 2:03
12  
Is your friend's name... Yoda? –  Adrian Aug 4 '11 at 16:36
    
and there are languages with polish notation and others with rpn –  jk. Aug 4 '11 at 18:57
3  
Just a side note: Khan Academy has some lessons on Python for beginner programmers: khanacademy.org/#computer-science and Google has some for more advanced: code.google.com/edu/languages/google-python-class/set-up.html –  lindon fox Aug 9 '11 at 2:54

12 Answers 12

up vote 44 down vote accepted

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.

share|improve this answer
15  
@FarmBoy: in mathematics, assignment and equality ARE the same thing, as there is no sequence in a formula as there is in computers. ( a equals b and at the same time b equals a ) –  Petruza Aug 4 '11 at 3:17
1  
@FB except in some single assignment functional languages like e.g. Erlang. Assignment and Assuring equality are the same like in mathematics –  Peer Stritzinger Aug 4 '11 at 6:00
8  
@Petruza No, in mathematics assignment and equality are not the same thing. If I say 'Let x = 2y - 3' it is different from 'Thus x = 2y - 3'. I math, typically context differentiates them. Since The comment disputing me was so universally acclaimed, I'll mention that I do have a Ph.D. in mathematics, I'm pretty sure about this. –  Eric Wilson Aug 4 '11 at 12:32
1  
@Petruza, I would like to add as proof that context tells us whether or not we are assigning or evaluating equality. |x + y|^2 = < x + y, x + y > is a very famous equality. Also, if I was proving this I might even write--not really, I would use the Schwarz, but this is an example so whatever-- : Suppose that | x + y |^2 = <x+y, x+y> then .... This would be similar in language though maybe not completely in function to if(|x + y|^2 == <x+y, x+y>) { ... }. Anyways, my point is, context is indeed the determining factor. –  Jonathan Henson Aug 4 '11 at 14:31
2  
@Petruzza - but there is sequentiality. Mathematical documents are written from start to end, the same as any other document. If I assert x = 1 in chapter one, but assert x = 2 in chapter two, that isn't some terrible contradiction - each assertion applies only within a certain context. The difference in imperative programming is partly the removal of a barrier (we don't need a change of context), and partly about implementation and usefulness. –  Steve314 Aug 5 '11 at 8:27

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

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

share|improve this answer
3  
... and in French, 81 is said as "four times twenty one" ... :) –  Martin Sojka Aug 4 '11 at 7:25
1  
@Martin, I believe Danish is very similar. –  Michael Kjörling Aug 4 '11 at 9:29
4  
@Martin That's really weird, because four times twenty one is 84. –  Peter Olson Aug 4 '11 at 15:17
4  
@Peter: you've got your parenthesis wrong, it's (four times twenty) one –  TokenMacGuy Aug 4 '11 at 20:36
3  
@Job: Reading your "If 18 yo Mary is ...", I was inevitably reminded of Yoda saying "When nine hundred years old you reach, look as good you will not, hmm?" in Return of the Jedi :-) –  joriki Aug 6 '11 at 17:32

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.

share|improve this answer
    
Precisely the point that I had thought of, yes. –  voithos Aug 8 '11 at 0:31

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.

share|improve this answer

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! :-)

share|improve this answer

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'!)

share|improve this answer
    
+1 I totally forgot that ! TI Basic was my very first language, too, but I don't remember this detail. –  barjak Aug 4 '11 at 7:51
1  
+1. It was the same on casio calculators. –  back2dos Aug 4 '11 at 8:37
    
Actually the STO operator is closer to how the machine works, and how any language actually operates. The value is first calculated and then stored in memory. –  Kratz Aug 4 '11 at 12:44
    
Thanks for this great example! –  voithos Aug 4 '11 at 21:20

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

share|improve this answer

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.
share|improve this answer

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.

share|improve this answer
2  
yes you do. in most languages the right side is evaluated before the left one. –  Javier Aug 4 '11 at 4:35
3  
Its a "Driving on the Right side of the road" type of thing. It seems logical but only because its the way you have always done it. All superior countries drive on the Left. –  James Anderson Aug 4 '11 at 8:33
    
@JamesAnderson superior countries? :o –  nawfal Jul 22 at 21:00
    
You're right, it's only logical for a left to right writing system as the roman alphabet, which I guess is used by almost every programming language, if not all. –  Petruza Jul 24 at 0:35

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.

share|improve this answer
1  
I understand your explanation, but could not the compiler just look ahead until the end of the statement? –  voithos Aug 3 '11 at 22:57
    
That might make the lexer simpler in today's languages, but how many programming languages even supported named methods, let alone method overloads, when this kind of syntax was new? –  Michael Kjörling Aug 4 '11 at 9:27
1  
Hi @voithos. Yes - the compiler could look ahead, but that would probably have been an unacceptable level of complexity in the early days of compiler writing - which was often hand-coded assembler! I think that putting the assigned variable on the left is a pragmatic choice: it's easier for both man and machine to parse. –  Dave Jewell Aug 4 '11 at 9:55
    
I think it would be trivial for an assignment to assign to the right. When a expression like 3+4==6+7, both sides are evaluated before the operator is, because the language is defined recursively. The language element 'variable = expression', could easily be changed to 'expression = variable'. Whether or not that causes ambiguous situations depends on the rest of the language. –  Kratz Aug 4 '11 at 12:51
    
@Kratz - that's certainly true for compilers now, but there may have been a minor issue for very old interpreted languages that worked with tokenized source. OTOH, that might have favored variable-on-the-right rather than variable-on-the-left. –  Steve314 Aug 5 '11 at 9:59

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.

share|improve this answer
    
Yes, but I suspect that the text in the editors would be right-aligned as well... –  voithos Aug 3 '11 at 22:55
8  
You can't generalise like that about assembly languages. They vary as to where the destination operand is. –  quickly_now Aug 3 '11 at 23:09
2  
@quickly_now: right; in fact, most of the primitive machine languages (not even assemblers by today's standards) didn't even have destination, as there was usually just one or two general-purpose accumulators. most operations implied the accumulator as destination, except for 'store' opcodes, which specified only the memory address and not the source (which was the accumulator). I really don't think it was any influence on assignment syntax for ALGOL-like languages. –  Javier Aug 4 '11 at 4:34
1  
@Tangurena - Some assembler languages have the destimation on the left. Not of the opcode (that's the assembled object code), but the left of the arguments list for the instruction mnemonic. However, others have the destination on the right. In 68000 assembler, you'd write mov.b #255, d0, for instance, where d0 is the register to assign to. Older assemblers only have a single argument per instruction. In the 6502 LDA #255 (Load Accumulator), you could argue that the A is on the left, but it's also on the left in STA wherever (Store Accumulator). –  Steve314 Aug 5 '11 at 9:05
1  
And even the Intel 4004 (the 4-bit ultimate ancestor of the 8086 family, with the 8008 and 8080 in between) was developed after assignment in high level languages. If you're assuming that the 8086 series is representative of what assemblers did in the 50s and earlier, I very much doubt that's true. –  Steve314 Aug 5 '11 at 9:10

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.

share|improve this answer
7  
I suppose that this form is more natural when program lines are considered as "statements" as opposed to "operations." As in, I declare that X must equal THIS, instead of the more linear Evaluate THIS and store it in X –  voithos Aug 3 '11 at 22:26
    
Wait, BASIC was an 'early' computer language? –  Alex Feinman Aug 4 '11 at 18:12
2  
@Alex Considering that it harkens from the 1960s, I'd say that's pretty early. –  Ben Richards Aug 4 '11 at 21:32
1  
On the other hand, in COBOL you could write MULTIPLY HEIGHT BY WIDTH GIVING AREA, so the variable that gets the result is on the very right side of the statement. –  user281377 Aug 5 '11 at 9:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.