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?


13 Answers 13


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.

  • 20
    @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
    Commented Aug 4, 2011 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 Commented Aug 4, 2011 at 6:00
  • 20
    @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. Commented Aug 4, 2011 at 12:32
  • 2
    I don't know mathematics anywhere near a PhD, what I state is that as there is no sequentiality, there's no order of execution in mathematics both in an assignment or in an equality, unlike programming, in which both sides of an assignment can be different at some point in time, and they end up being equal at some other point in time. But in mathematics, in an assignment like let a be... as there is no time, both sides of the assignment are equal as well, so the assignment is in fact an equality, no wonder why both use the same sign: =
    – Petruza
    Commented Aug 4, 2011 at 18:47
  • 5
    @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.
    – user8709
    Commented Aug 5, 2011 at 8:27

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


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.

  • 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
    Commented Aug 3, 2011 at 22:26
  • Wait, BASIC was an 'early' computer language? Commented Aug 4, 2011 at 18:12
  • 2
    @Alex Considering that it harkens from the 1960s, I'd say that's pretty early. Commented Aug 4, 2011 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
    Commented Aug 5, 2011 at 9:14

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.


(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))
Ans→{variable name}

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

  • +1 I totally forgot that ! TI Basic was my very first language, too, but I don't remember this detail.
    – barjak
    Commented Aug 4, 2011 at 7:51
  • 1
    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
    Commented Aug 4, 2011 at 12:44

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


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

  • 4
    ... and in French, 81 is said as "four times twenty one" ... :) Commented Aug 4, 2011 at 7:25
  • 8
    @Martin That's really weird, because four times twenty one is 84. Commented Aug 4, 2011 at 15:17
  • 7
    @Peter: you've got your parenthesis wrong, it's (four times twenty) one Commented Aug 4, 2011 at 20:36
  • 2
    In French it's actually four twenty and one, then four twenty two (sans and) up to four twenty ten nine (99).
    – Jon Purdy
    Commented Aug 5, 2011 at 6:07
  • 4
    @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
    Commented Aug 6, 2011 at 17:32

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

  • I think this is the best example here because it perfectly illustrates a context in a language where it's readable to a common English speaker but has right assignment. I'm saying that's important because of the large amount of people saying in English it would only read left to right for the assignment to make sense, which is absolutely not true. Commented Aug 16, 2018 at 18:48

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


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();

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

function() = identifier;

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.

  • Precisely the point that I had thought of, yes.
    – voithos
    Commented Aug 8, 2011 at 0:31

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.

  • 2
    I understand your explanation, but could not the compiler just look ahead until the end of the statement?
    – voithos
    Commented Aug 3, 2011 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?
    – user
    Commented Aug 4, 2011 at 9:27
  • 2
    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. Commented Aug 4, 2011 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
    Commented Aug 4, 2011 at 12:51
  • 1
    @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.
    – user8709
    Commented Aug 5, 2011 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.

  • Yes, but I suspect that the text in the editors would be right-aligned as well...
    – voithos
    Commented Aug 3, 2011 at 22:55
  • 8
    You can't generalise like that about assembly languages. They vary as to where the destination operand is. Commented Aug 3, 2011 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
    Commented Aug 4, 2011 at 4:34
  • 3
    @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).
    – user8709
    Commented Aug 5, 2011 at 9:05
  • 2
    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.
    – user8709
    Commented Aug 5, 2011 at 9: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! :-)


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.


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


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.


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.

  • 3
    yes you do. in most languages the right side is evaluated before the left one.
    – Javier
    Commented Aug 4, 2011 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. Commented Aug 4, 2011 at 8:33
  • 1
    @JamesAnderson superior countries? :o
    – nawfal
    Commented Jul 22, 2014 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
    Commented Jul 24, 2014 at 0:35

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