Living Museum of Learning
The Cube Learns a Language
Ivy's 14-day experiment had already taken an unexpected turn.
On the first day, we had started with something that looked like pure geometry: the golden ratio, three perpendicular golden rectangles, and eventually the 12 vertices of an icosahedron.
By the next class, those 12 vertices had become a spinning 3D object in p5.js.
Then came the next challenge:
Let's make something like a Rubik's Cube in Xcode.
But before writing the Rubik's Cube, there was a much more fundamental problem.
A physical Rubik's Cube has 6 faces and 54 visible cells.
How should we represent them in a program?
Ivy first experimented with indexing the cells using more than one cube in her diagram.
Then she asked:
“Index all the cells on one picture?”
That question was exactly what I wanted.
Because the goal wasn't merely to give every cell a number.
We wanted an indexing system that would make three future questions easy:
Which cells belong to that layer?
Which cells move together?
Where does each cell go?
I told her:
“Our indexing should make answering the above 3 questions easy.”
That changed the nature of the exercise.
We were no longer labeling a picture.
We were designing a representation for a future machine.
Ivy came back with a much richer diagram.
She didn't simply put numbers on the 54 cells.
She added a letter in front of each index number to identify the face:
F: FRONT
U: TOP
R: RIGHT — right of the front
L: LEFT — left of the front
B: BACK — opposite to front
D: DOWN — opposite to top
Suddenly, the numbers had meaning.
A cell was no longer just “17” or “42.”
Its label told us where it lived on the physical cube.
The cube now had a language.
I replied:
“This is a very detailed indexing now. Hopefully it'll guide our implementation of a Rubik's Cube. :D”
And that last word — hopefully — was deliberate.
We don't yet know whether this representation will be good enough.
The real test will come when we try to implement the cube's operations.
Can the indexing tell us which cells belong to a layer?
Can it tell us which cells move together?
Can it tell us where every cell goes after a rotation?
If yes, then the representation has done its job.
Something fascinating was happening.
Ivy had not yet built the Rubik's Cube.
She was designing the language in which the Rubik's Cube would later be described.
That is a very different kind of programming.
A beginner often starts by asking:
“What code should I write?”
An engineer eventually starts asking:
“How should I represent this thing so that the code becomes easier to write?”
Ivy was beginning to ask the second question.
And the six letters are more important than they might first appear.
F, U, R, L, B, D establish a fixed orientation.
Once that orientation exists, we can talk about a layer without pointing at a physical cube.
We can talk about relationships between cells.
We can describe movements.
We can eventually describe rotations.
And perhaps most importantly, Ivy and I now have a common language for discussing the object.
Instead of:
“That square on the upper-left side of the thing…”
we can eventually say:
“The U-layer cells…”
or:
“What happens to this F cell when the R layer rotates?”
The physical puzzle is slowly becoming a mathematical and computational object.
Ivy is learning something much deeper than how to draw a Rubik's Cube.
1. Representation comes before implementation.
A poor representation can make a simple operation confusing.
A good representation can make a difficult operation almost obvious.
2. Indexes can carry meaning.
A number alone tells us very little.
A structured label such as a face identifier plus an index tells us something about the geometry of the object.
3. Future operations should influence present design.
We don't want an indexing system merely because it looks neat.
We want one that helps us answer:
Which cells belong together?
Which cells move together?
Where does each cell go?
4. A physical object can become a computational model.
The real Rubik's Cube exists in the physical world.
Our program needs a precise model of that cube.
The journey is:
physical cube → visual representation → indexing → data model → operations → program
5. Engineering often begins with questions rather than answers.
Ivy doesn't yet know whether her indexing system is perfect.
Neither do I.
And that's okay.
We will find out by trying to use it.
If the representation makes the next problem easier, we keep it.
If it creates confusion, we redesign it.
That is not failure.
That is engineering.
A Rubik's Cube can be transformed from a physical puzzle with 54 visible cells into a precise computational model that a program can reason about.
Don't rush into implementation. First design a representation with enough structure to answer the operations the program will eventually need to perform.
The quality of a program often depends on decisions made before the first real line of code is written. Learning to choose a useful representation is a fundamental engineering skill.
Ivy's diagram itself becomes part of the exhibit.
The icosahedron was her first encounter with a beautiful mathematical object that she could construct and rotate.
The Rubik's Cube is becoming something different:
an object she has to teach the computer how to understand.
That's a very worthy next door after the 10-minute icosahedron. 😄