Answers.Body: <p>There is a recent thread on the SIGCSE mailing list about whether assignment uses &quot;labels&quot; or &quot;boxes&quot; as an explanatory mechanism. I actually prefer &quot;references&quot;, which is a bit like labels but more abstract. And I avoid boxes like I avoid the pandemic.</p>
  <p>To explain <em>assignment</em>, therefore, I wouldn't use the word &quot;assignment&quot; itself, but the word &quot;associate&quot;.</p>
  <blockquote>
  <p>Assignment associates a name with a value.</p>
  </blockquote>
  <p>Note &quot;with&quot;, not &quot;to&quot; in the description, so being symmetric avoids your dilemma. You can substitute &quot;and&quot; for &quot;with&quot;.</p>
  <p>Note that the reference model for both objects and primitives is consistent if you keep in mind that the real difference is that some &quot;values&quot; are mutable and some are not.</p>
  <p>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...).</p>
  <p>The &quot;name&quot; might be complex (array entries: a[i] = ...) and even involve other associations (i in the previous example).</p>
  <p>Note that the &quot;complex&quot; 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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-26T13:45:04.630Z
Answers.Text: *"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 (...)
Answers.UserDisplayName: Stef
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-26T13:45:26.207Z
Answers.Text: (continued) so that it's not "ingrained" like you say, by the time the students get to pointers and arrays.
Answers.UserDisplayName: Stef
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-31T07:13:17.160Z
Answers.Text: 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.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-31T07:18:58.587Z
Answers.Text: 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.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-17T12:09:31.347Z
Answers.LastActivityDate: 2021-08-17T12:09:31.347Z
Answers.UserDisplayName: Buffy
Body: <p>Does it matter if when explaining assignments like <code>a = 10</code> or <code>f = &lt;function&gt;</code> we talk about &quot;assign a value/object to a name&quot; or &quot;assign a name to a value/object&quot;? I was wondering if the latter shows more clearly that <code>a</code> or <code>f</code> are labels with stick on an independent value/object?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-18T02:00:03.927Z
Comments.Text: Assignment is a [bad construct](https://cseducators.stackexchange.com/a/6568/8837). Don't teach them (too early) if you've any say in the matter. The creator of assignment said so [most clearly](https://amturing.acm.org/award_winners/backus_0703524.cfm). And mutation is [even worse](https://cseducators.stackexchange.com/questions/2808/why-would-mutation-be-considered-by-some-as-a-difficult-concept-to-grasp/6567#6567). Stated more positively: teach functional programming
Comments.UserDisplayName: Rushi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-19T18:40:55.520Z
Comments.Text: 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.
Comments.UserDisplayName: Solomon Slow
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-19T18:41:14.537Z
Comments.Text: \* Don't ask me to talk about C++.  Just don't!
Comments.UserDisplayName: Solomon Slow
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-20T03:50:58.270Z
Comments.Text: 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.
Comments.UserDisplayName: Rushi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-20T03:51:33.820Z
Comments.Text: [Bob Harper](http://www.cs.cmu.edu/~rwh/pfpl/2nded.pdf)
   (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...»
Comments.UserDisplayName: Rushi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-20T03:53:29.233Z
Comments.Text: That's Bob Harper senior Prof at CMU who has [kicked out OOP](https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/)
  from the CMU core curriculum for being "anti-modular and anti-parallel" 
Comments.UserDisplayName: Rushi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-20T13:27:40.617Z
Comments.Text: @Rusi, Yes. That is one of the most important things that new programmers--especially if they come from a math background--need to learn: The traditional meaning of "variable" in the nomenclature of procedural programming languages always is different from what it means in mathematics. Looks like Bob Harper wants to fix that.
Comments.UserDisplayName: Solomon Slow
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-20T13:34:04.630Z
Comments.Text: @Rusi, Re, "no suggestion or implication of a process in time." In math, "time" _is_ a "space." A mathematical space is a continuum that can represent a physical space, or time, or some metric on the stock market, or any of an endless list of increasingly abstract ideas.
Comments.UserDisplayName: Solomon Slow
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-26T13:49:31.120Z
Comments.Text: @SolomonSlow That's a good point ; when discussing an algorithm in a mathematical proof (for instance to prove its correctness), a variable `x` from the algorithm should not be translated into a mathematical variable `x`, but into a **sequence** of variables `x_t` describing the value of `x` at time `t`.
Comments.UserDisplayName: Stef
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-08-31T07:05:59.080Z
Comments.Text: @SolomonSlow You are correct that mutation is confusing. The solution to this is not to teach that assignment and variables in programming are different to maths. The solution is to avoid mutation, for as long as possible. I do this when teaching python (python has mutation, but we don't have to use it). In the structure and interpretation of computer programs  (lecture version) we get to about hour 20 (½ way through the course), before mutation is used.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-09-03T00:57:54.307Z
Comments.Text: I think that if we tell students that a computer is an electrical machine that holds integer values in memory locations, and that new values can be placed there, then assignment will not be mystifying. If we explain that a memory location can hold the address of another memory location, then indirect reference will also be understood. With that, basically you have fully explained what is important about how computers differ from all other things in the universe. How does this get overlooked?
Comments.UserDisplayName: Scott Rowe
Tags: <programming>
Title: Perspective on assignments
ThreadText: # Perspective on assignments
  
  (Asked by: username_0 on 2021-08-17)
  
  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?
  
  **Tags:** programming
  
  > **Comments:**
  > **username_1**: Assignment is a [bad construct](https://cseducators.stackexchange.com/a/6568/8837). Don't teach them (too early) if you've any say in the matter. The creator of assignment said so [most clearly](https://amturing.acm.org/award_winners/backus_0703524.cfm). And mutation is [even worse](https://cseducators.stackexchange.com/questions/2808/why-would-mutation-be-considered-by-some-as-a-difficult-concept-to-grasp/6567#6567). Stated more positively: teach functional programming  
  > **username_2**: 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.  
  > **username_2**: \* Don't ask me to talk about C++.  Just don't!  
  > **username_1**: Your points are important and well taken @username_2. 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.  
  > **username_1**: [Bob Harper](http://www.cs.cmu.edu/~rwh/pfpl/2nded.pdf)  (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...»  
  > **username_1**: That's Bob Harper senior Prof at CMU who has [kicked out OOP](https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/) from the CMU core curriculum for being "anti-modular and anti-parallel"   
  > **username_2**: @Rusi, Yes. That is one of the most important things that new programmers--especially if they come from a math background--need to learn: The traditional meaning of "variable" in the nomenclature of procedural programming languages always is different from what it means in mathematics. Looks like Bob Harper wants to fix that.  
  > **username_2**: @Rusi, Re, "no suggestion or implication of a process in time." In math, "time" _is_ a "space." A mathematical space is a continuum that can represent a physical space, or time, or some metric on the stock market, or any of an endless list of increasingly abstract ideas.  
  > **username_3**: @username_2 That's a good point ; when discussing an algorithm in a mathematical proof (for instance to prove its correctness), a variable `x` from the algorithm should not be translated into a mathematical variable `x`, but into a **sequence** of variables `x_t` describing the value of `x` at time `t`.  
  > **username_4**: @username_2 You are correct that mutation is confusing. The solution to this is not to teach that assignment and variables in programming are different to maths. The solution is to avoid mutation, for as long as possible. I do this when teaching python (python has mutation, but we don't have to use it). In the structure and interpretation of computer programs  (lecture version) we get to about hour 20 (½ way through the course), before mutation is used.  
  > **username_5**: I think that if we tell students that a computer is an electrical machine that holds integer values in memory locations, and that new values can be placed there, then assignment will not be mystifying. If we explain that a memory location can hold the address of another memory location, then indirect reference will also be understood. With that, basically you have fully explained what is important about how computers differ from all other things in the universe. How does this get overlooked?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_6 on 2021-08-17. Score: 5
  
  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.
  
  > **Comments:**
  > **username_3**: *"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 (...)  
  > **username_3**: (continued) so that it's not "ingrained" like you say, by the time the students get to pointers and arrays.  
  > **username_4**: 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.  
  > **username_4**: 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.  
  
  ---
  
  