Working around language quirks

Question

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

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 by 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 4

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.)

Answer 5

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 6

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.

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: