CompareBooleanToConstant
DRAFT
Not Observed

Misconception:

To determine whether an expression evaluates to true or false, one must use the () = () block, to compare the value of the expression with a constant.

Incorrect

To test whether an expression evaluates to true or false, one must compare it to a constant

Correct

To test whether an expression evaluates to true or false, one can just use it

Correction
Here is what's right.

Such a comparison is entirely unnecessary.

This can be simplified to:

This applies to all uses of the equality operator to compare a boolean value to a constant:

ExpressionEquivalent Simplified Expression

Note that if mouse down? on its own would somehow be a convenient shortcut for mouse down? = true, then one would have to convert mouse down? = true to (mouse down? = true) = true, ad infinitum.

The following two expression trees illustrate this point: the simpler tree (with just the mouse down? node) actually appears within the more complicated tree, and thus to deeply understand the complicated tree, one would need to understand the simpler tree: i.e., that it means to evaluate mouse down?, which is going to produce the exact value we are looking for.

Argumentation

One may want to ask a student with this misconception which of the following two snippets they prefer, and why:

Then one can ask which of the following they prefer:

Finally one can discuss what just writing age—and just writing stop—actually means.

One may also want to ask a student whether they would ever say “I am hungry is true” instead of just saying “I am hungry”. In a way, the former could be seen as a low-level statement, where one is concerned about “hungry” being a variable, while the latter is a higher-level statement, where “hungry” just means what it usually means.

While in our experience the above arguments do not always lead to a change in practice or attitude (i.e., students might continue to write explicit comparisons), we believe they help to provide a deeper understanding of expressions.

Origin
Where could this misconception come from?

NOTE — We are not aware of repeated observations of this misconception in Scratch. We documented it, for completeness, based on observations of an equivalent misconception in other languages.

This misconception may go back to textbooks and instructors using the term condition to describe what goes into the holes of control blocks, and that Scratch uses hexagonal holes and hexagonal blocks to represent booleans:

Students may thus assume that a condition is a separate syntactic construct, and is different from an expression. This may include assumptions that a condition must including a comparison, or that it must test whether a variable contains a specific value, or even that only a small number of very specific conditions are possible (i.e., that conditions cannot be arbitrarily composed the way expressions can be).

Value
How can you build on this misconception?

This misconception provides an opportunity to discuss that conditions are expressions (expressions producing a boolean value).

Moreover, it provides an opportunity to a discuss the power of composition, and how expressions can be composed of all kinds of subexpressions.

Stay up-to-date

Follow us on  twitter to hear about new misconceptions.