A Left-Brain Right-Brain Puzzle

A while ago I picked up a brain-teaser puzzle from Mastermind Toys. (Didn’t the shop used to be Mastermind Educational? I guess the old name was from a time when even a daycare centre would call itself a “centre for early learning”.) The neat thing about this puzzle is that it is actually two puzzles in one – one puzzle for your left brain and one puzzle for your right brain.

The puzzle is requires you to assemble six pieces; each piece is composed of two through seven unit cubes. Here are the pieces:

The left half of the brain is associated with logic and reasoning. The left-brain puzzle calls on you to assemble the six pieces into a 3x3x3 cube. No surprise here:

The right half of the brain is associated with intuition and emotion. It was a while before I realized there is a right-brain puzzle here as well. The pieces can be placed in a way that spells out a message that appeals to your right brain, or perhaps to the right brain of someone special that you know. Do you see it?

And finally, when you’ve finished solving the puzzle, there’s yet another puzzle, not of mind power but of manual dexterity, when you try to wrap it up with a single elastic band.

Bonus Discourse

This puzzle is a distant cousin of the better-known Soma cube. Instruction sheets that come with Soma puzzles usually show that the seven pieces of the puzzle can be assembled into not only a cube but into a variety of sculptures including the bed and the sofa. It turns out that someone has made a version of the puzzle that can be assembled into life-sized Soma furniture including the Soma bed.

Structured Programming and Unstructured Artifacts

Most common programming languages consist of three essential sub-languages. (There may be other sub-languages such as a macro facility and I/O formatting.) Each of these sub-languages have structures for building useful programs out of atoms of data and computation, and each sub-language also contains an unstructured artifact that lets you escape the constraints of structures. When you use an unstructured artifact, you gain freedom to go wild in your code, but you inevitably make your code less comprehensible and more defect-prone. You might think that use of unstructured artifacts would be discouraged, but in fact attitudes have been uneven.

Structured and Unstructured

Here is a summary of the three sub-languages with their structuring mechanisms and unstructured artifacts.

Structuring Principle	Sub-Language
	Algorithm Structure	Data Structure	Expression
Structures within a Module
Sequence	Block of statements one after the other	Record or Struct	Ordinary formula, e.g., 2 * X + 1
Alternation	‘If’ / ‘Case’ statement	Variant-record or Union	Conditional formula, e.g., A>B ? A : B
Repetition	‘For’ / ‘While’ / ‘Until’ statement	Array or List	–
Structures to link Modules
Definition	Subroutine	Object	Function
Invocation	Call to the subroutine	Use of the reference to the object	Call to the function from within a formula
Unstructured Artifact
Artifact	‘Go to’ statement	Pointer	Flag variable

We figured out quite a long time ago that unstructured artifacts only bring grief to people (including yourself at a future time) who must read and modify your code, and that you can just about always replace unstructured artifacts in your code with structures that deliver the same results.

Programming using structured techniques is like driving using rules of the road. Sure, in some given situation you could get ahead by driving however you want. Widespread driving without rules, however, causes everyone to always arrive later at their destinations and more frustrated. To put it another way: to make use of an unstructured artifact is a way to avoid thinking through your code when you’re designing it, but at a cost of future efforts to read and understand code that is, in essence, an un-thought-out tangle.

The Pointer and the Go-To

But unstructured artifacts do not all have the same reputation. While the ‘go to’ statement was vilified as far back as the late 1960s, the pointer remained in programmers’ good graces for more than twenty years after. In 1968, Edsger W. Dijkstra published his famous letter “Go To Statement Considered Harmful” (original here^{[payment required]}, copy here), and within ten years programmers had thoroughly spurned the use of ‘go to’ statements. In contrast, pointer variables for a long time were quite respectable; indeed, C programmers have long been taught how to make routine use of pointers in their code. Most C programming novices struggled to comprehend C’s pointers and pointer arithmetic, yet this was seen not as an indictment of the pointer but as a sign that C programming is just inherently tricky.

We are improving. ‘Go to’ statements were eliminated through deliberate changes to programming practices and how programming was taught. Pointer variables have been disappearing as a side effect of programmers adopting programming languages built on principles of object orientation.