The Silicon Door

The key

The first constraint: access to compute

In 1981 the only computer I could reach lived in a locked office at Elmwood, my old elementary school in Rosemère, Quebec. It was an Apple II with 48 kilobytes of memory, and the school rationed it the way schools ration anything precious: a few supervised minutes at a time, for children young enough to still go there. I was fourteen and already at Rosemère High. Officially, I had no business anywhere near it.

So I made a key. I filed down a copy until it turned the lock. On nights I didn’t have it, I hid in a supply closet or behind the stage curtains until the custodians finished their rounds and the building went quiet. Then I let myself into the office, flicked the rocker switch, and listened to the disk drive grind and chatter while the screen came up green.

I stayed four or five hours at a time, most nights of the week. When I was done I climbed out a ground-floor window, eased it shut and walked home in the dark with my pages folded inside my jacket.

Nobody ever caught me. I never took anything but time on the machine. And that time decided the next forty-five years.

Radio Shack

Hardware first: logic gates, then loops

It started with sound. In the late seventies the Radio Shack near us kept analog synthesizers on display, and I went in to stand next to them. The store also sold the Science Fair 100-in-1 electronic kit, a board of springs and parts you wired together by hand. I built radios and oscillators with it, and then, from a few transistors and resistors, the tiny logic gates every chip is made of: AND, OR, NOT. I didn’t know that’s what they were called. I knew that if I wired them right, the circuit made a decision.

Then the TRS-80s arrived on the sales floor. I learned just enough BASIC to write a loop that filled a row of demo monitors with the names of the bands I loved, Bowie, Gary Numan, Bauhaus, over and over until a manager pulled the plug. It always ended the same way, and it didn’t matter. I’d learned that a few lines of code could take over a room.

A world in 48 kilobytes

State modelling: a whole world held in memory

What pulled me back to Elmwood night after night was Zork. If you never played it: a screen of text tells you where you are, you type what you want to do, GO NORTH, TAKE LAMP, OPEN DOOR, and the game answers. I’d also met ELIZA, the famous program that played a therapist by turning your own words back on you. ELIZA felt like a trick. Zork felt like a place. I wanted to build a place.

So I started my own: roads and cornfields, cellars and tunnels, objects you could carry, characters you could meet, conditions that changed as you moved. I had no training and no book on how games were made. I had Applesoft BASIC, a stack of loose-leaf paper and a lot of nerve.

The first thing a world teaches you is that it has to live somewhere. A flat list of variables can’t hold rooms that lead to other rooms. One page in my notebook is headed VARIABLE MAP: a key to the whole game in eleven lines. What the player typed. Where each object sat. Its short and long descriptions. The direction the player meant to go, their sector on the map, the time of day.

Another page works out where the exits go. Every room got six possible directions: north, south, east, west, up and down. The exits for every room lived in one long list, and to find a room’s six, you multiplied its number by six and counted forward. I wrote it as V = SCTR*6. Beside it, in pencil, are the rows themselves. Room 2 reads 3, 0, 4, 0, 0, 0: it opens onto rooms 3 and 4, and nowhere else.

Then came the fun part, filling it. The road is a block of program lines starting at 3010: an introduction, a major description, then a counter that changes the description as time passes. Along it runs Cornwall, a wall of maize. Lines 3032 to 3038 roll the dice on a hedgehog slipping into it, or an ear of corn turning up. If the clock lands on 7, 10 or 13, a hole in Cornwall is discovered and the game sends you through to sector 9. And lines 3056 to 3068 give a random chance of a horse coming along, then set the mood.

Deeper in there’s a tunnel system and an old elevator: “You are in an old ’30s style elevator… heavily corroded. It looks functional though.” The lever is rusted and needs force. A sealed mason jar of grease can only be smashed in certain places, and the notes list what it does once it breaks. It makes some floors slippery and soaks into others. It oils old machinery. A certain beast will eat it and become your friend. It burns.

I didn’t have words for any of it. I was designing systems.

Teaching it to listen

Input parsing: from keystrokes to words to intent

The world was the easy part. The hard part was letting a person talk to it.

Zork’s parser set the bar for what a home computer could understand, and I wanted mine to understand more than a short list of commands. The surviving code shows where I started. It reads what the player types into an array of up to a hundred slots, and if they keep going past that, it answers VERBAL OVERLOAD, REDO. Then it walks back through the characters, and every time it finds a space, CHR$(32) in Apple BASIC, it closes one word and starts the next. The header on the page is three lines long: INPUT. PARSE, put input into word form. SUBROUTINE, alter or list variables. That is still the basic shape of a command parser.

Splitting a sentence into words is mechanical. Knowing what the words mean is not. A page headed VOCABULARY works out that different words can point to the same action: take, get and procure all lead to the same place. Another page says only this: I JUMP ROPE. I FEVERISHLY JUMP ROPE. THE ROPE IS GOOD FOR JUMPING. Then, underneath: AFTER VERB AS WELL. I was working out that an adverb changes how something happens, that it can sit on either side of the verb, and that the same word, jump, can be an action in one sentence and the purpose of an object in the next.

An atom named cat

Semantic representation: meaning as a web of relationships

Somewhere in those pages, the project stopped being a game.

If you build a dictionary for a parser, the obvious move is to treat each word as a label. CAT means cat: a string of letters stored at an address. The more I worked on mine, the less that held up. A word on its own meant nothing. What made cat mean cat was everything it connected to: animal, small, soft, a predator, a pet, a thing that purrs. Some of those connections mattered more than others. Change them and you change the word.

I started thinking of each noun as an atom: nothing in itself, defined entirely by its bonds.

The notebook doesn’t have a diagram of a cat. It has something more interesting. Every kind of noun, idea, thing, person, place, gets the same three axes: SIZE, SHAPE, CLASSIFICATION. Beside them are the questions I wanted the machine to handle. WHAT IS THE LIFESPAN OF A HUMAN? CAN YOU BE LESS GENERAL THAN HUMAN? Underneath, copied out in capitals, the definitions I was working from: a verb tells what anything does, what was done to it, or in what state it is. A noun is a word used to denote any object of which we speak.

One line, on a page crowded with drawings of heads, says the part I could never put into code.

The mind usually sets certain standards for considering information. These standards are not objective.

At fourteen I had no idea I was standing next to anyone else’s work. A little further on, I’ve set the pages beside the published ideas they come closest to.

What “it” means

Context memory: resolving references across turns

The parser’s hardest problem was the smallest word. Type TAKE THE LAMP, then LIGHT IT, and the program has to know what it is. People do this without thinking. Programs don’t.

My answer is on a page full of sketches: CHECK LAST NOUN IN MEMORY THAT CORRESPONDS TO PRONOUN. Keep track of the nouns the player has used, and when a pronoun arrives, reach back for the most recent one that fits. In the margin of the same page I wrote ELEPHANT DISKS, a brand of floppy that went on sale in 1982. That’s how I know roughly when I worked it out.

Working out what a pronoun points to has a name, anaphora resolution, and a famous ancestor. Terry Winograd’s SHRDLU, built at MIT around 1970, let you talk to a simulated world of blocks and ask it to put it in the box. It ran on a research computer with a lab behind it. Mine ran on an Apple II in a school office after dark, and handled far less. It was the same kind of problem, worked out alone.

Side by side

Parallel discovery: the notebooks beside the published research

Here is the honest version of how close the pages come. On the left, what I worked out alone in Rosemère. On the right, the nearest published work, most of it from MIT, written by people with labs, funding and years of training. I hadn’t read a word of it. I’d only played the game in the last row.

Today’s language models learn their own version of that web from enormous amounts of text, every word a point defined by its neighbours. They got there by a road nobody in 1981 could have built, and my notebooks didn’t pave any of it. What the pages show is narrower, and to me more interesting: the idea was sitting there for anyone who pushed hard enough on the problem. Whether those pages earn a footnote in that history isn’t mine to decide. That’s for historians of computing, and I’m asking them.

The screen is for a person

Interface design: what the user sees, and when

One page I don’t remember writing is headed PROBLEMS. The list: designing output. Error messages. Door routine. Incorporation of text files. Under it, a rule: print the area description only once while in it, unless the character wishes to look. Beside it is a sketch of the screen itself, a title bar reading CORNWALL, a box for the description, a line at the bottom for input.

I was fifteen, deciding what the player should see, when to show it, and what to leave out so the screen didn’t drown them. There was no name for that job yet, at least nowhere I could see. It’s the job I’ve done ever since.

The math showed up late

Formal methods: the theory arrives after the need

I was failing math at the time. Not doing poorly. Failing.

Then the teacher reached algebra, and something happened that surprised us both. Binomials, functions, letters standing in for other things: I’d been trying to invent exactly these, badly, to describe position and movement and relationships in my world. The tools already existed. I’d just been ignoring the class where they lived.

I didn’t discover new mathematics. What happened was smaller, and it stuck: I needed the math before anyone taught it to me, and when it arrived, I recognized it.

The ceiling was the hardware

Scale: when compute, not the idea, is the limit

As the game grew I fought the machine for every byte. I ran parts of it through the Einstein compiler so they’d run faster, and dropped into assembly for the few routines where speed mattered most. Even then, the Apple II ran out of room long before the ideas did.

Near the end I remember a clear thought. It isn’t on any page I’ve found, so I’ll give it to you as memory, not evidence: this wasn’t a game anymore. It was the beginning of a thinking machine, and what held it back wasn’t the idea. It was the hardware, too little memory and too little speed. Given enough of both, a web of atoms like this would become something that could actually understand.

I had no idea how that would happen. I was sure that it would.

The veil

The through-line: designing how people and machines understand each other

I’ve thought a lot about why a teenager could get there at all. Part of it was obsession: four hours a night, most nights, for two years. The bigger part was what I didn’t know. Nobody had told me which problems were hard, which ideas belonged to universities, or that a kid with an Apple II wasn’t supposed to be working on them. I couldn’t see the walls, so I never stopped at them.

In the same years I filled a yellow notepad with poems and half-formed philosophy. One line reads like a manifesto now: what is real is what is experienced.

Every generation has kids like that, sitting in front of whatever the new machine is, pushing on it until it gives. Most of what they find has already been found. Some of it hasn’t. All of it matters, because the habit of pushing is the part that lasts.

That habit took me from a school office to game design, to a studio of my own, and into enterprise software, where I’ve since led design organizations at NielsenIQ and IBM. Most recently, that meant defining how AI behaves inside products people rely on: what it should do when it’s uncertain, and what it should do when it’s wrong.

The machinery is unrecognizably bigger now. Models learn their webs of meaning from more text than anyone could read in a lifetime, on hardware a fifteen-year-old in 1981 couldn’t have imagined. But when I sit down with an AI system today, the questions are the ones on these pages.

The scale changed. The questions didn’t. That’s the next story.

The notebook, page by page

Scroll sideways · tap a page to enlarge