To choose obfuscation
Salen and Zimmerman's Rules of Play has a whole chapter dedicated to various definitions of "game". The most memorable one for me was by Bernard Suits, from his book The Grasshopper: Games, Life, and Utopia:
Playing a game is the voluntary effort to overcome unnecessary obstacles.
Several of my ideas for learning games involve interfaces whose function is deliberately obscure, which only become usable through experimentation. This is common in games such as Myst, which is in essence a series of poorly documented interfaces, but why would I want to do this in a game that is trying to teach something? Wouldn't I want to make explanations and controls as straightforward and self-explanatory as possible? There are good reasons for explicit or representative explanations, but I think that they are out of place in games, where we have a different set of powerful tools available.
As I've discussed briefly before, the skill of extracting meaning from data is an important one. In a game we provide opportunities to discover the meanings of objects and commands, ideally constructed in such a way that incorrect inferences prove untenable.
If one has to work to figure out what something means, it can be more meaningful than simply being told what it means. It is important to make that discovery in a context where that meaning actually means something. Being told that a boomerang stuns an enemy for 5 seconds is much less significant than discovering how fast you need to run to be out of danger when he recovers. My recent post was about the development of this kind of understanding in games.
Relying on a symbol with a readable name like "if", "then" or "while" brings in all manner of unintended meaning. In Preprogramming Knowledge (PDF), Bonar and Soloway call this SSK: Step-by-Step natural language programming Knowledge. Because of the surface similarities between Pascal's keywords and English, the wrong meanings can be inferred. For instance, "while" is sometimes thought to describe the "demon control structure", which continuously tests the condition of the loop (i.e., the body of the loop is only processed while the condition holds). This is a natural thing to assume based on the usage of the English word "while", but it is quite different from the actual behavior of the Pascal construct.
Using graphical icons, like an arrow pointing up to mean "forward", is likewise rife with difficulty. If the "forward" arrow is a command for a robot to move forward, what does it mean when the robot is facing in a different direction than the arrow? Even arrows consistently indicating cardinal directions have the overloaded meaning of pointing at things, such as the icons surrounding them.
In psychological research on memorization, it has long been common to use nonsense syllables, in order to avoid triggering associations that might aid memorization. Leaving aside how to define meaningfulness, this allows the syllables to take on meaning only in relation to the environment in which they are presented. In a programming learning environment, when we are trying to introduce complicated concepts and behaviors, I think we would do well to follow this practice. While the inferences initially made may be wrong, they are more likely to be wrong because our presentation hasn't shown them to be wrong yet, rather than polluted by concepts brought in from outside that we can't plan for.