# Perspective on assignments

Does it matter if when explaining assignments like a = 10 or f = <function> we talk about "assign a value/object to a name" or "assign a name to a value/object"? I was wondering if the latter shows more clearly that a or f are labels with stick on an independent value/object?

• Assignment is a bad construct. Don't teach them (too early) if you've any say in the matter. The creator of assignment said so most clearly. And mutation is even worse. Stated more positively: teach functional programming
– Rusi
Aug 18 at 2:00
• If those are assignments (as opposed to declarations,) and if the language is any procedural language other than C++,* then a and f are not abstract labels "stuck on to" a value or an object. They are variables. They are concrete locations in memory into which a value or a reference to an object may be stored, and the assignment represents the run-time action of storing the value or the reference. Aug 19 at 18:40
• * Don't ask me to talk about C++. Just don't! Aug 19 at 18:41
• Your points are important and well taken @SolomonSlow. Yet I need to say that they reiterate a mistake by misunderstanding the misnomer — "variable". The English word "vary" of course is used for time-varying and is common language. But "variable" was almost exclusively math-speak at least until FORTRAN. And it always meant space-varying. The math : "Let x be a complex variable" means quite unambiguously "x can take any value from the space C". There is no suggestion or implication of a process in time.
– Rusi
Aug 20 at 3:50
• Bob Harper (pg 311) Prof at CMU: «The language maintains a sharp distinction between variables and assignables. Variables are introduced by λ- abstraction, and are given meaning by substitution (timeless). Assignables are introduced by a declaration, and are given meaning by assignment and retrieval of their contents... (in time). Expressions evaluate to values, and have no effect on assignables. Commands are executed for their effect on assignables...»
– Rusi
Aug 20 at 3:51

There is a recent thread on the SIGCSE mailing list about whether assignment uses "labels" or "boxes" as an explanatory mechanism. I actually prefer "references", which is a bit like labels but more abstract. And I avoid boxes like I avoid the pandemic.

To explain assignment, therefore, I wouldn't use the word "assignment" itself, but the word "associate".

Assignment associates a name with a value.

Note "with", not "to" in the description, so being symmetric avoids your dilemma. You can substitute "and" for "with".

Note that the reference model for both objects and primitives is consistent if you keep in mind that the real difference is that some "values" are mutable and some are not.

A given name can be associated with only one value at a time in a given context, but the context may be limited (scope...). The association can be changed or not depending on other factors (const...).

The "name" might be complex (array entries: a[i] = ...) and even involve other associations (i in the previous example).

Note that the "complex" name case, above, starts to break down. But, by the time that you get to arrays in a course, the idea of an assignment will already be so ingrained that the complication is unlikely to arise. If it does, just say that your original metaphor wasn't perfect, as few are.

• "But, by the time that you get to arrays in a course, the idea of an assignment will already be so ingrained that the complication is unlikely to arise." There are many courses on C programming which consider that variables and assignment are a simple concept that will be easily understood by every student, but that pointers and arrays are super complex and won't be understood easily. And indeed students tend to fail when they arrive at the "pointers" part of the course. In many cases, this is due to the course not properly explaining the concept of assignment, so that (...)
– Stef
Aug 26 at 13:45
• (continued) so that it's not "ingrained" like you say, by the time the students get to pointers and arrays.
– Stef
Aug 26 at 13:45
• You say that you prefer reference to label, but then use name (Which means label). Therefore, it looks like you prefer label. I also like label: One reason for this is that the label can be associated with a reference, or a value. Aug 31 at 7:13
• The primitives vs non-primitives distinction is unique to Java: Mutable/immutable, value/reference, and primitive/non-primitive, are all independent concepts, and should be orthogonal in the language design. However, Java (somewhat) ties them together. Aug 31 at 7:18