It will soon be six months since I started my Code Year pledge with codecademy.com. I’m still going strong. I’ve even started beta testing a few courses ahead of time. But this doesn’t mean that learning to program has been easy.
All my new learning is at the fresh cement stage. If I don’t take stock while I can still see the rocky road behind me, I become useless to the people still on it. So, I’ve decided this would be a good time to write about one of my biggest stumbling blocks coming out of the gate.
It was that damn = sign, and the subtle, but really important ways that this sign is different in imperative programming than it is in arithmetic and algebra.
For those of us who never continued with math beyond high school, = has a pretty rigid meaning. It means “the same as”. Things on each side of it evaluate as the same. Sure, we understand that the value of a variable can change. If x = y + 1 in one algebra exercise, we accept x = 2y + 1 in the next one. But essentially, what isn’t supposed to change is that both things on each side of that symbol have the same value.
In JavaScript, however, = means something more like “attached to”. Or “associated with” or “same type” or “contains all of these things” or is the same as “for a limited time only!”, depending on the context in which it is being used.
Much of coding is building quickie archives of associations, archives that can just as quickly be dismantled. So programming needs an equal sign to have a much broader, less sticky meaning than it does in math. In math the equal sign is like glue. In programming it’s more like a post-it note.
For instance x = 0 used in a programming algorithm usually does not really mean x is equal to 0. It’s a way of saying that x is a number and it will be starting at 0. So if we put x in a standard programming loop like (x = 0; x < 10; x++) it means that x’s value is going to increase in numerical value by one, each of the 10 times we run that loop.
If we write x = ” ” then what we’re saying is that x is a string, i.e. some kind of phrase, which usually means x will be used as a container for whatever words or sentences we want to plug into x.
If we want to make x stand for a particular series of actions, we turn it into a function by writing x = function (). That series of actions will be repeated every time we write x().
X can also be an array, a list of things, as in x = [1, train, $, 104, poodle].
In programming if you want to convey that something is actually equal in the way normal people understand equal, you add an extra =, or just to be safe two extra equal signs, x === y. This gives x what is called a “Boolean” value, i.e. the variable either is or isn’t exactly this thing. For example:
if (x === 3) {do this thing};
in this case x has to be 3 for the action in between the curly brackets to be executed.
if (x !==3){do this thing};
means do this thing only if x isn’t 3.
Write: if (x=3) {do this thing}, and the computer will spaz out because your definition of x is too vague, so it doesn’t know what to do.
****
If you learn to program with a bright sixth grader, as I did, you may find that they grasp this floaty = concept much faster than you do.
Sixth graders don’t have to unlearn the = sign because they’ve just started learning algebra. Their brain has just freshly opened to the fact that an equal sign can be used in more interesting ways than previously known.
If your sixth grader is anything like my sixth grader, he or she may very well kick your ass in the first twenty hours of programming, as you stumble again and again over whether that variable is the “same as “ or “sort of like” something, and hurt your brain further, trying to figure out why it’s attached to that meaning in one place of the algorithm, but not in another place.
Even when I understood the difference theoretically, my brain kept reading the sign badly again and again. It was like that Stroop Test, where someone shows you the word BLUE written in green ink. When they ask you the color of the ink, you keep saying blue because your brain prioritizes the language definition over the visual. My brain was clamped on equal being equal, even when I knew it wasn’t.
“But wait!”, you and an unfortunate number of other educators might say. “If we expose children too early to the more complex and nuanced programming concept of = won’t they get all confused when they learn algebra? Don’t they need a period of time when the = sign has a more limited scope?”
You may even develop this idea further. “What if after being exposed to all this = sign confusion, some children end up learning algebra [cue music to soundtrack from Psycho] at a slower rate. What horrible things will this do to their self esteem? Maybe they’ll give up and refuse to learn algebra all together, in total frustration!”
This is the argument used by those who think only really, demonstrably super smart kids should be exposed to programming in middle school. Ideally in expensive summer coding camps reserved just for them. And this is probably the argument that will solidify the growing gap between the technologically literate, and the now merely language literate, for much longer than it should exist.
It’s also the argument that will keep girls from mastering code as a matter of course, since they don’t tend to sign up for summer coding camp as frequently as boys, and by the time the girls are given the option of learning programming, they’ve developed a misconception about computer science as something only of interest to social isolates (var nerdyGeek = “social isolate”).
This is the same reasoning people use when they bring up studies that show children raised in bilingual environments exhibit a significant language delay. (Trilingual environments, they argue are even worse!)
I can only argue against this from anecdotal experience. But I will argue against it, passionately.
I’m a Montrealer, so my son, Ben, learned English at home, but went to daycare in our French speaking neighborhood. To make matters “worse”, I had joint custody with his father, who was born in Israel and spoke to him in Hebrew.
Indeed, this created a significant language delay, to the point where, when he was two, we had his hearing tested just to be sure.
But there was no hearing problem. And not only was there no hearing problem, by the time Ben hit kindergarten he was reading fluently in both French and English, counting to a 1,000 and already starting to grasp a little multiplication. Because by then, his brain was a language learning machine.
Ben’s not a genius (he’s been WISC tested. Apparently he’s at the high end of average). He’s just a smart kid whose brain now codes information a little faster than normal kids because he spent his early years in an information rich environment where there was a lot more meaning to sort out.
If your child maintains a coding practice, even if it does cause a little confusion at first, it’s a good guess he or she will not be falling behind on the math curve for long. In fact, before you know it they will probably be three times as equal as the other kids.
Or if you want to contemplate a really scary scenario [Psycho refrain] they will probably become three times as equal as you.
familyCoding 
Hi Juliet, nice blog!
The easiest way to think about = is “assignment”, i.e. you are assigning that value to the variable. In the following where you said:
“Write: if (x=3) {do this thing}, and the computer will spaz out because your definition of x is too vague, so it doesn’t know what to do.”
That’s not exactly technically correct. What is happening is that by writing x=3 you are telling the program to assign 3 to the variable x. When you put something in the if(….) bracket, the if is always assessing a Boolean value– what this means is that because you can ALWAYS assign 3 to x as an operation, this Boolean value is always true– hence the if statement will mess up because is not evaluating whether x equals 3, but whether you are assigning x with 3 (which will always be true, since that’s what you did in the brackets!)
Thanks for explaining that to me.
I’m still working out the nuances. I’ve learned something important from your explanation. What you’re telling the computer with the === in the if loop, is that x may not always be equal to 3. As opposed to the assignment =, which tells the computer that x is always 3–unless you put x in a for loop and then x goes back to being evaluated, since a for loop is really just shorthand for a while statement, where you would be using the === statement if you wrote it out the long way.
Yes, thats more correct, but I think a better way to think about it is to understand what parameters go into the function. For if and while, the paramater that goes in the brackets (i.e. if(….), or while(….) is always Boolean, which means something indicating true or false. Hence it will turn the x=3 into the Boolean value that it returns. For a for loop, the parameters that go in are: for(start value, finish value, iteration), which are not evaluating true or false but actually performing operations and checking the start and stop points.
Something that I try to do when I learn new functions in a language is to also google for the actual function syntax, which will tell you very clearly what each variable that goes into the brackets is supposed to do.
Pingback: The (English) language of programming | run( ) {