Answers.Body: <p>It depends on the programming level of the students. In my case, students are just starting out with Java. I tell them to ignore the quirks and multiple ways of doing things (e.g., adding 1 to an int var). Find a way the works and go with it. Then discover the different ways as you progress with the language. These students are new to basic programming concepts and problem solving. Language syntax shouldn't stand in their way.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T13:18:42.350Z
Answers.LastActivityDate: 2017-07-26T13:18:42.350Z
Answers.UserDisplayName: Edwin Torres
Answers.Body: <p>In Bertrand Myers book/course (I have only read the book) “Touch of Class”, he deals with this, by first teaching a language with few quirks (Eiffel). Then at the end of the course/book, after all of the concepts have been learnt, he teaches C♯, Java, C and C++, by teaching how to translate Eiffel code into each of these. It is at this point that he would cover the quirks of the languages.</p>
  
  <p>He has claimed that it is quicker to teach Eiffel then all 4 of the other languages at the end, than it is to teach any one of them from the start.
  Unfortunately I can not give testimony to this, as I already knew C, C++, and several other languages by the time I learnt Eiffel. However I now realise that I did not truly know C++, until I first learnt Eiffel.</p>
  
  <p>Therefore first <strong>avoid</strong>, by using a better language such as Eiffel, and then <strong>embrace</strong> by teaching how the other language(s) relate to Eiffel. (<em>See other answers on how to embrace.</em>)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T16:02:21.103Z
Answers.Text: Isn't this just deferring the problem though? I'd argue that *all* programming languages have quirks of some kind. You can avoid having to teach as many quirk by starting with a better-designed language, true, but it doesn't seem like you can avoid the problem entirely. (For example, here's one example of an Eiffel quirk: methods are covariant in their argument types, rather then being contravariant)
Answers.UserDisplayName: Michael0x2a
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T09:00:08.510Z
Answers.LastActivityDate: 2017-07-26T09:00:08.510Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <p>Since most of the answers here already provide a good pedagogical approach, I'm going to add one element you can use to completely shift the tone when these moments occur: <strong>use a meme.</strong> <strong>Find humor in the absurdities.</strong> I strongly believe that well-placed humor in the classroom is of instructional benefit.</p>
  
  <p>My reasoning as humor applies to this particular topic comes from the "Wat" talk given by Gary Bernhardt. In it he uses the "Wat" meme to point out some rather absurd characteristics of Ruby and JavaScript. The video is only a little over four minutes long and can be found <a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow noreferrer">here</a>.</p>
  
  <p>Teaching with memes can be a memorable and funny experience for students, and it then becomes something they can continue to reference. Befuddled by why a language has a quirk that it does? Make a meme of it. Share it. Tweet it. Put it up on a classroom wall. The drastic difference in tone will help students create that cognitive separation between those big picture items and those more quirky items by which you don't want them to be distracted.</p>
  
  <p>Sometimes we don't need to take a serious, intellectualized approach; comedy can work in aiding the learning process.</p>
  
  <p>Here's an example based on what you list above:</p>
  
  <p><a href="https://i.sstatic.net/vntvl.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/vntvl.jpg" alt="&quot;Wat&quot; meme example in JavaScript"></a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-28T03:22:55.000Z
Answers.Text: Aha!  So someone else *did* mention this talk.  It was my first thought on reading the question.  :)
Answers.UserDisplayName: Wildcard
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-27T21:23:49.060Z
Answers.LastActivityDate: 2017-07-27T21:23:49.060Z
Answers.UserDisplayName: Peter
Answers.Body: <p>One strategy that's sort of similar to the "embrace" strategy described in the other answers is "acknowledge" -- not only do you explore the quirk, you explicitly acknowledge that it's a flaw or mistake in the language.</p>
  
  <p>After all, languages are designed by humans, and humans are ultimately fallible creatures: I think it's ok to acknowledge in some cases that the language designers messed up, or were working under assumptions and constraints that are no longer relevant today. This lets you work in teaching moments about:</p>
  
  <ul>
  <li>The importance of planning and the realities of software maintenance/backwards compatibility</li>
  <li>The fact that everybody makes mistakes and its ok</li>
  <li>Demonstrate what balanced technical criticism looks like (as opposed to the annoying sort of "language fanboyism" some students seem to pick up) </li>
  </ul>
  
  <p>You can then amp back up the enthusiasm after you've moved past the quirk and returned to the actual content to help emphasize what you ultimately think is important and worth focusing on.</p>
  
  <p>To return back to your original question, I think whether or not you actually discuss quirks or brush over them depends on to what degree the quirks impact your students' ability to successfully write code.</p>
  
  <p>For example, take the <code>a == b</code> vs <code>a === b</code> thing in JavaScript. I would argue that sort of quirk is ultimately irrelevant in the grand scheme of things: the "always use <code>a === b</code>" rule is almost always what you want, so I would probably spend only a minute or so talking about the quirk (I'd probably spend most of that minute cracking jokes about JS, honestly), finish by mandating students must always use <code>a === b</code>, then move on.</p>
  
  <p>In other cases, trying to paper over or ignore quirks would be irresponsible. One example of this might be JavaScript's Byzantium rules on how exactly the <code>this</code> keyword is scoped. This issue actually does come up fairly frequently in practice (especially once you start mixing together object-oriented and functional style code), so is something you probably do actually need to cover in some detail -- at the very least, you need to give students a good set of rules of thumb they can apply. </p>
  
  <p>Another example might be <code>a == b</code> vs <code>a.equals(b)</code> in Java -- this distinction strikes at the core of several fundamental Java topics and so must probably be taught in detail at some point.</p>
  
  <p>There are unfortunately some quirks that fall into a middle ground: not so easily brushed aside, but not really worth spending time explaining (for example, the broken interaction between Java arrays and generics). In those cases, it might be worth just engineering your homework assignments so students simply never run into those quirks, or just writing that portion of the assignment for them, with comments for the curious.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T13:54:52.937Z
Answers.Text: I usually think about those as tradeoffs rather than mistakes.  *This language values ____, and that implies certain tradeoffs, such as this one.*
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T06:49:18.243Z
Answers.LastActivityDate: 2017-07-26T17:24:00.437Z
Answers.LastEditDate: 2017-07-26T17:24:00.437Z
Answers.UserDisplayName: Michael0x2a
Answers.Body: <p>In essence, you have two choices.  You can embrace the quirks, or you can hand-wave them away.</p>
  <h1>Embrace</h1>
  <p><em>&quot;Now, take a look at this code. What do you think it will do? Let's check it ou--- whoa!  What in the world just happened?  Turn to your neighbor and see if you can figure out what's going on.&quot;</em></p>
  <p>Give them a moment to get their thoughts outlined, and then have them come back, and together discuss what is actually happening.</p>
  <h1>Dismiss</h1>
  <p><em>&quot;So, you may want to be careful to avoid doing X.  For now, I recommend that you stick with Y.  X isn't wrong, but it has some unexpectedly complex behaviors, and we don't have time to go into them.  If you want to see for yourself when X is better, Google is absolutely available to you!  For the purposes of our assignments, however, I can promise you that you won't need it to be successful.&quot;</em></p>
  <h1>How to choose?</h1>
  <p>The main characteristic that I use to choose when to do a deep dive and when to skip it is by looking at whether the deep dive will support the goals of my class.  If it will give us a chance to practice using concepts that are important to the overall goals, then I will usually take the time to dive in.  Otherwise, I will probably skip it.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T04:06:10.007Z
Answers.Text: _Lions and Tigers and Bears! Oh my!_ but, please, let's not talk about the elephant! Say, what's that over there? Is that Kelly Pickler? No? Oh, sorry about that. Now where were we. Oh, yea, that ostrich over there. It seems to have a good idea. Now, can any one tell me how a while loop is made?
Answers.UserDisplayName: Gypsy Spellweaver
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T03:19:38.123Z
Answers.LastActivityDate: 2017-07-26T03:19:38.123Z
Answers.LastEditDate: 2020-06-18T08:36:57.023Z
Answers.UserDisplayName: Ben I.
Answers.Body: <p>If you don't want the students to get hung up on the language quirks for the language you are teaching, there are probably many ways to "work around" them. If you don't want the students to get hung up on the language quirks for the next language they have to use, either in school or out, and when you are not there to help, then you've really only got one choice. Teach them to understand <em>why</em> the quirks exist, and what is happening "behind the scenes" that makes them "work." </p>
  
  <p>The <strong>Embrace</strong> option given in the <a href="https://cseducators.stackexchange.com/a/2947/104">answer</a> by <a href="https://cseducators.stackexchange.com/users/27/ben-i">Ben I.</a> is a good example of how to do that. Show the "unexpected" behavior, then lead them on a path of discovery to explain the anomaly just observed. By discovering it they will <em>own</em> it, and be better able to discover the reasons for other anomalies when they are encountered elsewhere.</p>
  
  <p>By taking the <strong>Embrace</strong> route you are not only teaching the language in use at the time, you are also helping the students to develop reasoning skills. Skills that will help them reach their potential in whatever direction life takes them. A good Computer Science program <em>can</em> teach programming, in one language or another, as well as other computer science pathways. It can also teach, and hone, reasoning and analytic skills that are useful in many fields that are totally unrelated to computers, or even science. This is one of the common reasons (not the only, nor necessarily the main reason) that many schools, and school systems, have introduced Computer Science programs to their curriculum. Don't waste the opportunity to help your students develop those valuable skills by side-stepping, or hand-waving away, the quirks, which make such wonderful "teaching moments."</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-26T04:49:36.523Z
Answers.LastActivityDate: 2017-07-26T04:49:36.523Z
Answers.UserDisplayName: Gypsy Spellweaver
Body: <p>I find javascript to be a very pretty and neat language, once you understand how everything fits into a larger structure, which takes a lot of time and experience to understand. For many who haven't seen this inner beauty (for example, many of my JS students), they notice all kinds of "language quirks", which you can find enumerated all over the internet:</p>
  
  <pre><code>""           ==   "0"           // false
  0            ==   ""            // true
  0            ==   "0"           // true
  false        ==   "false"       // false
  false        ==   "0"           // true
  false        ==   undefined     // false
  false        ==   null          // false
  null         ==   undefined     // true
  " \t\r\n"    ==   0             // true
  </code></pre>
  
  <p><a href="https://bonsaiden.github.io/JavaScript-Garden/#types.equality" rel="nofollow noreferrer">Source</a></p>
  
  <p>Every language has its quirks (although few are as famous as JS in that regard), so what are some ways you've found effective to get students to focus on larger concepts instead of getting hung up on language quirks?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-26T03:23:14.340Z
Comments.Text: I love this question, and I am very curious about what others suggest as well.
Comments.UserDisplayName: Ben I.
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-26T17:16:10.713Z
Comments.Text: The great Josh Bloch teaches serious points about Java in an entertaining way with his Java Puzzlers book and talks.  http://www.javapuzzlers.com/
Comments.UserDisplayName: Ellen Spertus
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-28T03:15:33.377Z
Comments.Text: If you haven't seen the ["Wat" lightning talk](https://www.destroyallsoftware.com/talks/wat) (from CodeMash 2012), you'll enjoy it.  Very relevant.  :)
Comments.UserDisplayName: Wildcard
Tags: <conceptual-frameworks>
Title: Working around language quirks
ThreadText: # Working around language quirks
  
  (Asked by: username_0 on 2017-07-26)
  
  I find javascript to be a very pretty and neat language, once you understand how everything fits into a larger structure, which takes a lot of time and experience to understand. For many who haven't seen this inner beauty (for example, many of my JS students), they notice all kinds of "language quirks", which you can find enumerated all over the internet:
  
  ```
  ""           ==   "0"           // false
  0            ==   ""            // true
  0            ==   "0"           // true
  false        ==   "false"       // false
  false        ==   "0"           // true
  false        ==   undefined     // false
  false        ==   null          // false
  null         ==   undefined     // true
  " \t\r\n"    ==   0             // true
  
  ```
  
  [Source](https://bonsaiden.github.io/JavaScript-Garden/#types.equality)
  
  Every language has its quirks (although few are as famous as JS in that regard), so what are some ways you've found effective to get students to focus on larger concepts instead of getting hung up on language quirks?
  
  **Tags:** conceptual-frameworks
  
  > **Comments:**
  > **username_1**: I love this question, and I am very curious about what others suggest as well.  
  > **username_2**: The great Josh Bloch teaches serious points about Java in an entertaining way with his Java Puzzlers book and talks.  http://www.javapuzzlers.com/  
  > **username_3**: If you haven't seen the ["Wat" lightning talk](https://www.destroyallsoftware.com/talks/wat) (from CodeMash 2012), you'll enjoy it.  Very relevant.  :)  
  
  ---
  
  ## 6 answers
  
  ### Answer by username_6 on 2017-07-26. Score: 6
  
  One strategy that's sort of similar to the "embrace" strategy described in the other answers is "acknowledge" -- not only do you explore the quirk, you explicitly acknowledge that it's a flaw or mistake in the language.
  
  After all, languages are designed by humans, and humans are ultimately fallible creatures: I think it's ok to acknowledge in some cases that the language designers messed up, or were working under assumptions and constraints that are no longer relevant today. This lets you work in teaching moments about:
  
  * The importance of planning and the realities of software maintenance/backwards compatibility
  * The fact that everybody makes mistakes and its ok
  * Demonstrate what balanced technical criticism looks like (as opposed to the annoying sort of "language fanboyism" some students seem to pick up)
  
  You can then amp back up the enthusiasm after you've moved past the quirk and returned to the actual content to help emphasize what you ultimately think is important and worth focusing on.
  
  To return back to your original question, I think whether or not you actually discuss quirks or brush over them depends on to what degree the quirks impact your students' ability to successfully write code.
  
  For example, take the `a == b` vs `a === b` thing in JavaScript. I would argue that sort of quirk is ultimately irrelevant in the grand scheme of things: the "always use `a === b`" rule is almost always what you want, so I would probably spend only a minute or so talking about the quirk (I'd probably spend most of that minute cracking jokes about JS, honestly), finish by mandating students must always use `a === b`, then move on.
  
  In other cases, trying to paper over or ignore quirks would be irresponsible. One example of this might be JavaScript's Byzantium rules on how exactly the `this` keyword is scoped. This issue actually does come up fairly frequently in practice (especially once you start mixing together object-oriented and functional style code), so is something you probably do actually need to cover in some detail -- at the very least, you need to give students a good set of rules of thumb they can apply.
  
  Another example might be `a == b` vs `a.equals(b)` in Java -- this distinction strikes at the core of several fundamental Java topics and so must probably be taught in detail at some point.
  
  There are unfortunately some quirks that fall into a middle ground: not so easily brushed aside, but not really worth spending time explaining (for example, the broken interaction between Java arrays and generics). In those cases, it might be worth just engineering your homework assignments so students simply never run into those quirks, or just writing that portion of the assignment for them, with comments for the curious.
  
  > **Comments:**
  > **username_1**: I usually think about those as tradeoffs rather than mistakes.  *This language values ____, and that implies certain tradeoffs, such as this one.*  
  
  ---
  
  ### Answer by username_1 on 2017-07-26. Score: 3
  
  In essence, you have two choices. You can embrace the quirks, or you can hand-wave them away.
  
  # Embrace
  
  *"Now, take a look at this code. What do you think it will do? Let's check it ou--- whoa! What in the world just happened? Turn to your neighbor and see if you can figure out what's going on."*
  
  Give them a moment to get their thoughts outlined, and then have them come back, and together discuss what is actually happening.
  
  # Dismiss
  
  *"So, you may want to be careful to avoid doing X. For now, I recommend that you stick with Y. X isn't wrong, but it has some unexpectedly complex behaviors, and we don't have time to go into them. If you want to see for yourself when X is better, Google is absolutely available to you! For the purposes of our assignments, however, I can promise you that you won't need it to be successful."*
  
  # How to choose?
  
  The main characteristic that I use to choose when to do a deep dive and when to skip it is by looking at whether the deep dive will support the goals of my class. If it will give us a chance to practice using concepts that are important to the overall goals, then I will usually take the time to dive in. Otherwise, I will probably skip it.
  
  > **Comments:**
  > **username_8**: _Lions and Tigers and Bears! Oh my!_ but, please, let's not talk about the elephant! Say, what's that over there? Is that Kelly Pickler? No? Oh, sorry about that. Now where were we. Oh, yea, that ostrich over there. It seems to have a good idea. Now, can any one tell me how a while loop is made?  
  
  ---
  
  ### Answer by username_8 on 2017-07-26. Score: 2
  
  If you don't want the students to get hung up on the language quirks for the language you are teaching, there are probably many ways to "work around" them. If you don't want the students to get hung up on the language quirks for the next language they have to use, either in school or out, and when you are not there to help, then you've really only got one choice. Teach them to understand *why* the quirks exist, and what is happening "behind the scenes" that makes them "work."
  
  The **Embrace** option given in the [answer](https://cseducators.stackexchange.com/a/2947/104) by [username_1.](https://cseducators.stackexchange.com/users/27/ben-i) is a good example of how to do that. Show the "unexpected" behavior, then lead them on a path of discovery to explain the anomaly just observed. By discovering it they will *own* it, and be better able to discover the reasons for other anomalies when they are encountered elsewhere.
  
  By taking the **Embrace** route you are not only teaching the language in use at the time, you are also helping the students to develop reasoning skills. Skills that will help them reach their potential in whatever direction life takes them. A good Computer Science program *can* teach programming, in one language or another, as well as other computer science pathways. It can also teach, and hone, reasoning and analytic skills that are useful in many fields that are totally unrelated to computers, or even science. This is one of the common reasons (not the only, nor necessarily the main reason) that many schools, and school systems, have introduced Computer Science programs to their curriculum. Don't waste the opportunity to help your students develop those valuable skills by side-stepping, or hand-waving away, the quirks, which make such wonderful "teaching moments."
  
  
  ---
  
  ### Answer by username_4 on 2017-07-26. Score: 1
  
  It depends on the programming level of the students. In my case, students are just starting out with Java. I tell them to ignore the quirks and multiple ways of doing things (e.g., adding 1 to an int var). Find a way the works and go with it. Then discover the different ways as you progress with the language. These students are new to basic programming concepts and problem solving. Language syntax shouldn't stand in their way.
  
  
  ---
  
  ### Answer by username_5 on 2017-07-26. Score: 1
  
  In Bertrand Myers book/course (I have only read the book) “Touch of Class”, he deals with this, by first teaching a language with few quirks (Eiffel). Then at the end of the course/book, after all of the concepts have been learnt, he teaches C♯, Java, C and C++, by teaching how to translate Eiffel code into each of these. It is at this point that he would cover the quirks of the languages.
  
  He has claimed that it is quicker to teach Eiffel then all 4 of the other languages at the end, than it is to teach any one of them from the start.
  Unfortunately I can not give testimony to this, as I already knew C, C++, and several other languages by the time I learnt Eiffel. However I now realise that I did not truly know C++, until I first learnt Eiffel.
  
  Therefore first **avoid**, by using a better language such as Eiffel, and then **embrace** by teaching how the other language(s) relate to Eiffel. (*See other answers on how to embrace.*)
  
  > **Comments:**
  > **username_6**: Isn't this just deferring the problem though? I'd argue that *all* programming languages have quirks of some kind. You can avoid having to teach as many quirk by starting with a better-designed language, true, but it doesn't seem like you can avoid the problem entirely. (For example, here's one example of an Eiffel quirk: methods are covariant in their argument types, rather then being contravariant)  
  
  ---
  
  ### Answer by username_7 on 2017-07-27. Score: 1
  
  Since most of the answers here already provide a good pedagogical approach, I'm going to add one element you can use to completely shift the tone when these moments occur: **use a meme.** **Find humor in the absurdities.** I strongly believe that well-placed humor in the classroom is of instructional benefit.
  
  My reasoning as humor applies to this particular topic comes from the "Wat" talk given by Gary Bernhardt. In it he uses the "Wat" meme to point out some rather absurd characteristics of Ruby and JavaScript. The video is only a little over four minutes long and can be found [here](https://www.destroyallsoftware.com/talks/wat).
  
  Teaching with memes can be a memorable and funny experience for students, and it then becomes something they can continue to reference. Befuddled by why a language has a quirk that it does? Make a meme of it. Share it. Tweet it. Put it up on a classroom wall. The drastic difference in tone will help students create that cognitive separation between those big picture items and those more quirky items by which you don't want them to be distracted.
  
  Sometimes we don't need to take a serious, intellectualized approach; comedy can work in aiding the learning process.
  
  Here's an example based on what you list above:
  
  [!["Wat" meme example in JavaScript](https://i.sstatic.net/vntvl.jpg)](https://i.sstatic.net/vntvl.jpg)
  
  > **Comments:**
  > **username_3**: Aha!  So someone else *did* mention this talk.  It was my first thought on reading the question.  :)  
  
  ---
  
  