When you write an arithmetic expression with an equals sign in mathematics it means something very different to what it does in programming. For example, in math:

y = 123
x = y+42

means that x is exactly 165 and it always will be. Well, it will be until the symbol is reused in some other equation, probably on some other piece of paper. Mathematics is about static relationships and programming isn’t. When you write a symbol on the left of an equals sign the symbol is “bound” to what is on the right forever. In programming, the binding is temporary and you can write:

y = 123
x = y+42
x = 0

which mathematically is nonsense – how can x be both 165 and 0 at the same time?!

Of course, in programming the meaning is quite different because time is included in the description. The program:

y = 123
x = y+42
x = 0

isn’t a static statement about a single time. It is a dynamic process and each instruction occurs at a different time. First 123 is stored in the variable y. Then the contents of y are retrieved and 42 is added before being stored in x. Then x has 0 stored in it. No contradiction and x was bound to 165 at one time and to 0 at another.

Programming is about time and process – mathematics is about relationships.

Some people think that this is what makes programming so inferior to mathematics and they try to “correct” this perceived error. The best known attempt to reduce programming to mathematics is called functional programming and it makes programmers jump through hoops to get the job done in a way that is closer to math. Programming is inherently dynamic and that should be considered its advantage.

One Plus One Makes…

To see just how dynamic programming is, consider the following program:

x = 1
x = x + 1

What is x?

You may know the answer, but are you sure you have realized that from a mathematical point of view this is rubbish. There is no value for x which makes x+1 the same as x. That’s not how addition works and it’s not how programming works. If you read out loud exactly what the expression says then it all makes sense:

Store 1 in x. Retrieve the value in x and add 1 to it. Finally store the result back in x. What is x? Answer: x is 2.

Beginning programmers often have a lot of trouble with expressions like x = x+1 because they think they are something to do with mathematics. It has nothing to do with mathematics and everything to do with programming.

This instruction is an increment operation, i.e. it increments the value stored in x by 1. It is very commonly encountered and understanding it really well is often the first step in becoming a programmer.

In particular, when it is included in a loop it gives rise to a counting loop:

While condition
x = x+1

which counts the number of times the loop has repeated. If you use x in the condition you have an enumeration loop that repeats a given number of times:

x = 1
While x <= 5
x = x+1

In this case the loop repeats exactly five times with x counting each time through the loop – 1, 2, 3, 4, 5. In this case x is often called the loop index. There is a long tradition that variables used for counting in this way, loop indexes, are called i, j, k, l, m and n. The reason is that this was the convention in FORTRAN and, even though it isn’t necessary today, many programmers still use it. Part of the reason for this is that the use of i, j and k fits in with the mathematical convention of naming subscripts.

Not Equals

The problem with x = x+1 is almost entirely due to the use of the equals sign. The instruction isn’t x “equals” anything it is x “becomes” or “assign to x” or… well, anything is better than the static “equals”. Our hero Edsger Dijkstra was particularly strict on this matter:

The computer scientist David Gries recalled a time when he was lecturing with Dijkstra in the audience when he read "x=a" as "x equals a". This is of course a short hand for "assign a to x" and not a statement that x really is logically equal to a. From the back of the room Dijkstra shouted "becomes" and the room fell silent.

Gries thought about it for a moment and said,

"Thank you Edsger, for correcting me. If I make the same mistake again, stop me."

Everything went fine until twenty minutes later he made the same mistake when the shout from the back of the room came again - "becomes". Gries once again thanked Dijkstra and claims to never have made the mistake again. Other lecturers haven't been so lucky.

Yes, it really does matter. Not so much what you say, but what you think. If you say “equals” out loud but think “becomes” there will be no problem – unless you have an Edsger Dijkstra in your audience.

A commentary from the computer scientist Niklaus Wirth enlarges on the problem:

A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to FORTRAN in 1957 and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let “=” denote a comparison for equality, a predicate which is either true or false. But FORTRAN made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x.

Some computer languages have taken the problem to heart and dispensed with the equals sign for assignment. For example, Algol and Pascal, use := to mean assignment,, and R uses ←. The equals sign is so deeply entrenched that it is used by more and more languages and seems to be forever embedded in programming, despite carrying all the wrong overtones.

There is another small problem. What symbol do you use when you are trying to write a condition that tests for equality. What does:

If x = 0 Then..

mean? Does it mean set x to 0 and then do something else? Some languages allow you to use = to mean test for equality and they work out from the context if you actually mean assignment or test for equality. Other languages, the majority, insist that you use == or similar for a test of equality. So the If instruction should have been written:

If x == 0 Then

Once you get used to it this isn’t difficult, but it is error prone. If you accidentally write a single = then an assignment is made, not a test, and there will be no error messages to warn you.

Summary

A variable is somewhere you can store a value associated with a label, its name.

We only need to consider storing numeric values in variables as other types of data can be represented by a suitable code.

Finding good names for variables is an important and sometimes difficult problem.

Good names can make programs much easier to understand.

Values are stored in variables by assignment. The most commonly used symbol for assignment is the equals sign, but this doesn’t imply equality, it means store the value in the variable.

Retrieving the value stored in a variable is done just by using its name.

It is usual to extend assignment to allow assignment of the result of an arithmetic expression.

It is also usual to extend the definition of an arithmetic expression to allow variables to be included.

There are two ways that values enter a program – as literals and non-literals or variables.

Assignment is dynamic and a variable can hold different values as a program is executed.

In particular, an expression like x=x+1, which is nonsense in mathematics, represents counting in programming. It means “take what is in x and add one to it and store the result back in x”.

Meta Open Source is transferring Jest, its open source JavaScript testing framework, to the OpenJS Foundation. Jest is the most used testing framework measured by weekly downloads (17 million a week) [ ... ]