teaching machines

== true

November 11, 2017 by Chris Johnson. Filed under public, teaching.

When I was a junior in college, I lost a point on an exam because I had code like this:

if (isTall == true) {
  ...
}

Dr. Wallingford showed me with his red pen that == true is completely unnecessary. This is quite clear when you consider the truth table:

The second column is no different than the first.

Not only is == true unnecessary, it also makes the code unpronounceable. When we are first learning to program, it’s helpful if we stick close to natural language, especially when you find yourself writing != false.

These days I am the teacher. I never ever write == true in my examples, nor does our textbook. But my students write == true all the time, and I want them to stop. I’ve been reading Young Children Reinvent Arithmetic by Constance Kamii, who studied under Piaget, and this sentence from the first chapter caught my eye:

… to understand human knowledge [Piaget] believed that it was necessary to study its development rather than only the end product.

When I read that sentence, I am challenged. Instead of just wanting to rid my students’ code of == true, I find myself wanting to understand what’s going on in their brains that they (and I) would even write that.

My hypothesis is that we tend to introduce logic with numbers and the relational operators: >, >=, <, <=, ==, and !=. We fixate on the binary structure of these expressions and can’t depart from it when boolean operands are introduced. I can think of a few things we might try in order to investigate this further:

1. Introduce logic only with functions that yield booleans, not operators. For example:

   if isOrdered(x, y, z)
     ...
   elsif list.isEmpty
     ...

   This eliminates the binary structure altogether. If students do not initially see the binary structure when they’re cutting their logical teeth, would they not write list.isEmpty == true even after the relational operators are introduced?
2. Initially relegate all inequalities to variable assignments. For example:

   boolean isBiggerX = x > y
   if isBiggerX
     ...

   This practice would get students used to seeing single tokens in the condition. It would retain the binary structure in assignment expressions, but I would expect a lot of self-correction there from students when they write == true on the right-hand side. For one, the type of the variable is made explicit. You might realize that you already have a boolean. For two, coming up with a name for the variable takes on the value of isTall == true is awkward. The name isTall comes to mind, but you’ve already got that:

   boolean isTall = isTall == true

   Perhaps you’d realize that another variable is unnecessary?

For the time being, I do not understand what’s going on my students’ heads. However, the unit tests I distribute to them scan for == true in their code. If they want credit, contains better be false.