Answers.Body: <p>As always with javascript, show the right&amp;wrong:</p>
  
  <p>Show them, using the exact piece of code from your example, but add another line:</p>
  
  <pre><code>var greeting = "Hello ";
  var first_name = prompt("What's your first name?");
  var last_name = prompt("What's your last name?");
  
  var reply = greeting+" "+last_name+", "+first_name;
  console.log("reply");
  console.log(reply);
  </code></pre>
  
  <p>And run it. </p>
  
  <p>Then they see that when they <code>log</code> something with <code>" "</code>, the output is literally what's inside the quotes.</p>
  
  <p>However, if they have a <code>var</code>iable (this is important to note that <code>reply</code> is defined with <code>var</code>), the output is the contents of the variable. Truth be told, the output is the string representation of the object, but I fear that's too advanced at this point. </p>
  
  <p>Further explaining that when they use the word <code>var</code> (or <code>const</code> etc.), you create a something that <strong>holds</strong> information. On the other hand, using quotes <code>""</code>, you are simply representing that information.</p>
  
  <p>But no matter how well you <em>explain</em> it, it's still far more effective to <em>show</em> examples like the one above, and to give the students exercises that will allow them to <strong>experience</strong> the point you try to teach.</p>
  
  <p>For example, let them try to do that with a <code>Date</code> object:</p>
  
  <p>As an exercise, teach them about <code>Date</code> in JS:</p>
  
  <pre><code>var d = new Date()
  </code></pre>
  
  <p>and then explain that <code>d</code> holds info about the date and time that the line was executed. </p>
  
  <p>Once the students understand the very basics of the date object, ask them to print it. The difference between</p>
  
  <pre><code>console.log(d)
  </code></pre>
  
  <p>and </p>
  
  <pre><code>console.log("d")
  </code></pre>
  
  <p>are very, very big.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-24T08:45:27.297Z
Answers.LastActivityDate: 2018-02-24T13:50:35.773Z
Answers.LastEditDate: 2018-02-24T13:50:35.773Z
Answers.UserDisplayName: ItamarG3
Answers.Body: <p>Don't imagine that this problem is rare or that it is caused because the students don't "get it." Often they get it all too well. It is common in learning a new thing to base your understanding on what you already know about other things. This is just the sort of error I made myself as a beginning programmer, basing Fortran stuff on what I already knew about math (a lot, as a new PhD in math). The students who make this kind of error may, in fact, be very adept at using analogy to put the new information into a coherent framework. </p>
  
  <p>I think your solution is to first give them a good understanding of <em>symbol</em>. You can start with math symbols like + etc. A symbol "stands for" something, in this case addition. The symbol isn't itself addition, but "stands for" addition. Language punctuation symbols can be likewise shown as "standing for" something. For example semicolon usually stands for statement termination (or separation, depending on the language). In Python, spaces are actually symbols. </p>
  
  <p>From that you can progress to <em>word symbols</em>, such as <em>foo</em>. It is just a symbol, but is spelled out using some alphabet. It "stands for" something; perhaps a function. </p>
  
  <p>Now, you can introduce variable names as word symbols that "stand for" values. </p>
  
  <p>However literals, such as 5 and "foo" aren't symbols in the sense that they "stand for" something else. They stand for only themselves. So <em>foo</em> is a word symbol but "foo" is a literal. The former could stand for lots of different things, but the latter only for itself. </p>
  
  <p>Once they start to study languages in general, the concept of a word symbol will be important to them in any case, so this early introduction is good in a larger context. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-24T14:44:17.880Z
Answers.Text: +1 I love how you have re-cast the issue so that it puts the students into a good light. This is both a good approach, and a dignified and loving one.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-24T17:21:46.577Z
Answers.Text: Thanks. I note that a lot of issues like this are much more subtle than they appear at first glance. It is usually worth a second/deeper look before jumping to conclusions about ability, and other things. I've said many times here that "Your students are not like you."
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-24T13:47:53.983Z
Answers.LastActivityDate: 2018-02-24T13:47:53.983Z
Answers.UserDisplayName: Buffy
Body: <p>In my APCSP class (using <a href="https://code.org/educate/applab" rel="noreferrer">app lab</a>, which is javascript based), I noticed that there are many students who struggle with the difference between a string (<code>"foo"</code>) and a variable (<code>foo</code>). I've explained that strings are surrounded by quotes while variables are not, but this is still one of the most common mistakes I see. For example, a programming task could be:</p>
  
  <blockquote>
    <p>Create a prompt for a persons first and last names, and then print out a greeting (stored in a variable) followed by the name (last name, first name).</p>
  </blockquote>
  
  <p>and a student will write the following code:</p>
  
  
  
  <pre><code>var greeting = "Hello ";
  var first_name = prompt("What's your first name?");
  var last_name = prompt("What's your last name?");
  
  var reply = greeting+" "+last_name+", "+first_name;
  console.log("reply"); // &lt;-- Here's the problem
  </code></pre>
  
  <p>I typically see this issue when a student is trying to <em>output</em> information, either to the console or set a GUI element to have that text content. I also see it occasionally in other contexts, such as conditional statements.</p>
  
  <p>What can I do to help students better avoid this mistake?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-24T10:18:27.127Z
Comments.Text: Why not let them practice so they notice the difference between a variable and a value?   We all learn by doing mistakes.  Also, consider using examples with numeric values.
Comments.UserDisplayName: Michel Billaud
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-26T13:02:50.163Z
Comments.Text: Do they notice after testing? Why did I get the word “reply” appear in the log?  …
Comments.UserDisplayName: ctrl-alt-delor
Tags: <secondary-education><ap-cs-principles><syntax><variables><javascript>
Title: App Lab/JS confusion between strings and variables
ThreadText: # App Lab/JS confusion between strings and variables
  
  (Asked by: username_0 on 2018-02-24)
  
  In my APCSP class (using [app lab](https://code.org/educate/applab), which is javascript based), I noticed that there are many students who struggle with the difference between a string (`"foo"`) and a variable (`foo`). I've explained that strings are surrounded by quotes while variables are not, but this is still one of the most common mistakes I see. For example, a programming task could be:
  
  > Create a prompt for a persons first and last names, and then print out a greeting (stored in a variable) followed by the name (last name, first name).
  
  and a student will write the following code:
  
  ```
  var greeting = "Hello ";
  var first_name = prompt("What's your first name?");
  var last_name = prompt("What's your last name?");
  
  var reply = greeting+" "+last_name+", "+first_name;
  console.log("reply"); // <-- Here's the problem
  
  ```
  
  I typically see this issue when a student is trying to *output* information, either to the console or set a GUI element to have that text content. I also see it occasionally in other contexts, such as conditional statements.
  
  What can I do to help students better avoid this mistake?
  
  **Tags:** secondary-education, ap-cs-principles, syntax, variables, javascript
  
  > **Comments:**
  > **username_1**: Why not let them practice so they notice the difference between a variable and a value?   We all learn by doing mistakes.  Also, consider using examples with numeric values.  
  > **username_2**: Do they notice after testing? Why did I get the word “reply” appear in the log?  …  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2018-02-24. Score: 3
  
  As always with javascript, show the right&wrong:
  
  Show them, using the exact piece of code from your example, but add another line:
  
  ```
  var greeting = "Hello ";
  var first_name = prompt("What's your first name?");
  var last_name = prompt("What's your last name?");
  
  var reply = greeting+" "+last_name+", "+first_name;
  console.log("reply");
  console.log(reply);
  
  ```
  
  And run it.
  
  Then they see that when they `log` something with `" "`, the output is literally what's inside the quotes.
  
  However, if they have a `var`iable (this is important to note that `reply` is defined with `var`), the output is the contents of the variable. Truth be told, the output is the string representation of the object, but I fear that's too advanced at this point.
  
  Further explaining that when they use the word `var` (or `const` etc.), you create a something that **holds** information. On the other hand, using quotes `""`, you are simply representing that information.
  
  But no matter how well you *explain* it, it's still far more effective to *show* examples like the one above, and to give the students exercises that will allow them to **experience** the point you try to teach.
  
  For example, let them try to do that with a `Date` object:
  
  As an exercise, teach them about `Date` in JS:
  
  ```
  var d = new Date()
  
  ```
  
  and then explain that `d` holds info about the date and time that the line was executed.
  
  Once the students understand the very basics of the date object, ask them to print it. The difference between
  
  ```
  console.log(d)
  
  ```
  
  and
  
  ```
  console.log("d")
  
  ```
  
  are very, very big.
  
  
  ---
  
  ### Answer by username_4 on 2018-02-24. Score: 3
  
  Don't imagine that this problem is rare or that it is caused because the students don't "get it." Often they get it all too well. It is common in learning a new thing to base your understanding on what you already know about other things. This is just the sort of error I made myself as a beginning programmer, basing Fortran stuff on what I already knew about math (a lot, as a new PhD in math). The students who make this kind of error may, in fact, be very adept at using analogy to put the new information into a coherent framework.
  
  I think your solution is to first give them a good understanding of *symbol*. You can start with math symbols like + etc. A symbol "stands for" something, in this case addition. The symbol isn't itself addition, but "stands for" addition. Language punctuation symbols can be likewise shown as "standing for" something. For example semicolon usually stands for statement termination (or separation, depending on the language). In Python, spaces are actually symbols.
  
  From that you can progress to *word symbols*, such as *foo*. It is just a symbol, but is spelled out using some alphabet. It "stands for" something; perhaps a function.
  
  Now, you can introduce variable names as word symbols that "stand for" values.
  
  However literals, such as 5 and "foo" aren't symbols in the sense that they "stand for" something else. They stand for only themselves. So *foo* is a word symbol but "foo" is a literal. The former could stand for lots of different things, but the latter only for itself.
  
  Once they start to study languages in general, the concept of a word symbol will be important to them in any case, so this early introduction is good in a larger context.
  
  > **Comments:**
  > **username_5**: +1 I love how you have re-cast the issue so that it puts the students into a good light. This is both a good approach, and a dignified and loving one.  
  > **username_4**: Thanks. I note that a lot of issues like this are much more subtle than they appear at first glance. It is usually worth a second/deeper look before jumping to conclusions about ability, and other things. I've said many times here that "Your students are not like you."  
  
  ---
  
  