So I’m doing this one differently and diving straight into my impressions.

The poem

Do you remember an Inn,
Miranda?
Do you remember an Inn?
And the tedding and the spreading
Of the straw for a bedding,
And the fleas that tease in the High Pyrenees,
And the wine that tasted of the tar?
And the cheers and the jeers of the young muleteers
(Under the vine of the dark verandah)?
Do you remember an Inn, Miranda,
Do you remember an Inn?
And the cheers and the jeers of the young muleteers
Who hadn’t got a penny,
And who weren’t paying any,
And the hammer at the doors and the Din?
And the Hip! Hop! Hap!
Of the clap
Of the hands to the twirl and the swirl
Of the girl gone chancing,
Glancing,
Dancing,
Backing and advancing,
Snapping of the clapper to the spin
Out and in—
And the Ting, Tong, Tang of the Guitar!
Do you remember an Inn,
Miranda?
Do you remember an Inn?

Never more;
Miranda,
Never more.
Only the high peaks hoar:
And Aragon a torrent at the door.
No sound
In the walls of the Halls where falls
The tread
Of the feet of the dead to the ground
No sound:
But the boom
Of the far Waterfall like Doom.

Rereading it now

It is lively and rhythmic, and you almost can’t help but clap your hands to its beat. Of course, the twist at the end is unexpected and all the more devastating because of the upbeat tone of everything before it.

The images of the dancing and then the empty dance hall, with the distant sound of the waterfall of Doom, left a mark on me when I first read the poem. Rereading it now doesn’t change that at all.

Hearing it

I listened to this recording, thinking it was Belloc. I don’t think it was.

The inn I had always wondered about

The history and context I found were fairly sparse, and I didn’t learn much that wasn’t already in the poem. I’ve known the poem for a long time, though, and have occasionally wondered what inn—or what evening—would inspire him to write it.

A little research suggests, the inn may have been the Hotel Sisas in Canfranc, below the Somport Pass. Belloc mentions it in The Pyrenees, where he describes the cooking as “doubtful” and the wine as “so-so.” The Aragón, the inn and the bad wine all fit. He never says that this was the place behind the poem, though.

That is as close as I could get. I still do not know anything about the evening itself, or who Miranda was.

Neither the reading nor the context changed my sense of the poem. I still read it much as I did when I was a teenager.

The sound or image I kept thinking about

The image and sound I keep thinking about are, of course, the ghostly steps of non-existent dancers and the distant, dreaded boom of the waterfall.

Sources and versions

• Belloc’s 1923 collected text

• Belloc’s 1909 account of the Hotel Sisas and the inns around Somport

• The April 1921 magazine text

• Belloc’s 1919 manuscript record

• The reading I listened to—the reader is not identified

• Miranda Mackintosh’s correction

静夜思

床前明月光，
疑是地上霜。
举头望明月，
低头思故乡。

Jìng yè sī

Chuáng qián míng yuè guāng,
Yí shì dì shàng shuāng.
Jǔ tóu wàng míng yuè,
Dī tóu sī gùxiāng.

A simple, naive translation

Before the bed, bright moonlight—
I think it is frost on the ground.
I raise my head and look at the bright moon;
I lower my head and think of home.

Before I read a good translation

This took me back to being a child, still awake in bed late at night, when a full moon would peek out from behind the clouds. The frost made me picture crisp white blankets, matching the blanket I would be snuggled under while hiding from the cold.

There is something lonesome already about raising your head to look out of the window at the moon. Then the last line—“think of home”—really hits hard in the feels. It adds to the nostalgia.

I didn’t even attempt to sound out the Chinese myself because I have no familiarity with it. The first recording was much more sing-song and childlike than I expected. It made the poem sound almost upbeat, which did not match the homesickness I had pictured.

A more subdued reading still sounded upbeat to me. The words end with missing home, but the melody sounded happy.

After reading the translations

Of the four translations I read, I preferred Shigeyoshi Obata’s:

I saw the moonlight before my couch,
And wondered if it were not the frost on the ground.
I raised my head and looked out on the mountain moon;
I bowed my head and thought of my far-off home.

Obata’s came closest, although it still does not quite feel like the poem I had pictured. That is strange given that I know no Chinese at all and he was the expert. I can see part of the distance now: I had added a window, clouds, a full moon, and blankets. None of those things is actually in the poem. They came from me.

The biggest change was the frost. I had imagined real frost on the ground outside. Now I see it as the gleam of moonlight, briefly mistaken for frost until the speaker looks up. There may be no actual frost, but the night still feels chilly.

What I learned

I also discovered that there is more than one Chinese version of the poem. The familiar version says “bright moonlight” in the first line and “bright moon” in the third. Some early printed versions instead say “watching moonlight” and “mountain moon.” That is why Obata writes “mountain moon”: he was translating a different version, not adding scenery of his own.

The poem has only twenty characters, arranged in four lines of five. In modern Mandarin, the last words of lines one, two, and four—guāng, shuāng, and xiāng: light, frost, and home—rhyme. The final two lines also mirror each other: raise the head, lower the head; look at the moon, think of home.

It has also been memorized and repeated by generations of children. That made the childlike sound of the recordings less surprising. A homesick poem can also be a poem children know by heart.

Li Bai spent much of his adult life travelling. The last word, gùxiāng, means more than a house. It is an old or native place—the place someone comes from.

Rereading it

My first reading sent me back to childhood. Reading it again made me think about leaving home.

I left home a long time ago, and these days I often feel nomadic and untethered to any particular place. That makes the last line carry more weight, not less. I am not always sure which place I mean when I think of home. Rereading it brings a sting to my eyes.

The image I kept thinking about

I still picture the pale light of a full moon, almost unreachably far away and yet visible and seemingly graspable.

Sources and versions

• Original Chinese text

• First Mandarin recording

• More subdued Mandarin recitation

• Shigeyoshi Obata’s translation

• Witter Bynner and Kiang Kang-hu’s translation

• Herbert A. Giles’s translation

• L. Cranmer-Byng’s translation

• The poem’s textual history

• Form and rhyme

古池や
蛙飛びこむ
水の音

Furu ike ya
kawazu tobikomu
mizu no oto

A small invitation before the translation

Before you read a translation, try saying the romanized Japanese aloud and then listen to the recording. I wrote down what I pictured before I knew what the words meant. If you want to try the same experiment, stop here for a minute.

Then come back to this deliberately naive translation:

A simple, naive translation

An old pond—
a frog jumps in,
the sound of water.

Before I read a good translation

I picture an old green pond with algae, surrounded by drooping trees leaning over it. I can feel the coolness, as if there were a breeze, although there is no wind or movement.

The frog may have been there all along, camouflaged by the foliage. Then it jumps: a plop, circular waves spreading across the water, and the pond slowly settling again. If I close my eyes, I can almost smell the earth, greenery, and water—not fresh, but not stagnant either.

When I tried to say the Japanese, it sounded almost stochastic to me: jumpy, and not flowing off my tongue. Then I listened to the recording and realized I had been mispronouncing it. Spoken properly, it felt much more peaceful and much closer to the scene I had imagined.

What gets lost in translation?

W. G. Aston translated the poem this way in 1899:

An ancient pond!
With a sound from the water
Of the frog as it plunges in.

Lafcadio Hearn’s 1898 version is much barer:

Old pond—frogs jumping in—sound of water.

I prefer Aston’s translation because it feels closer to what I first imagined: tranquility, stillness, and one lonesome frog. Hearn’s plural “frogs” feels much more active. I start wondering what made all of them jump and what frightened them enough to break the stillness.

Japanese leaves the number open, but English makes the translator choose. I was surprised by how much that one choice changed the scene for me.

What I learned

I was surprised to learn that this very quiet scene came out of a social event. The poem dates to spring 1686 and opens Kawazu Awase—The Frog Contest—a collection of frog poems arranged in twenty paired contests after a gathering at Bashō’s hut.

Earlier Japanese poetry usually noticed the frog’s singing voice; kawazu was also a conventional spring word. Bashō pays attention to a different frog sound.

An account published six years later says Bashō had the final two lines first. Kikaku suggested opening with yamabuki ya—“yellow kerria—”—but Bashō chose furuike ya: “old pond—.” It is not a transcript, and it does not prove there was no real pond. Still, it made me wonder whether the sound came first and the pond came later.

Rereading after reading a couple of different translations

For me, the original image survives. Knowing that earlier poems paid attention to frogs singing makes Bashō’s choice feel a little cheeky: he listens to the plop instead. But even without that history, the poem was already vivid and meaningful to me.

The line or image I kept thinking about

The image I keep coming back to is an iridescent green-and-red frog disappearing with a plop and leaving a symmetric splash behind it.

One-sentence afterthought

I keep seeing the splash after the frog has disappeared.

Sources and versions

• Original text and historical variants

• Japanese reading

• W. G. Aston’s translation

• Lafcadio Hearn’s translation

• Kawazu Awase and the poem’s 1686 setting

• The transmitted account of the poem’s opening

First experiment: Two dozen poems peppering the days of September.

Subscribe now

There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors. This old joke highlights that naming stuff is notoriously tricky — and not just for programmers who can’t count.

What I actually mean is: names are not just labels. They’re interfaces. They carry assumptions. They leak context. And sometimes, they carry authority.

Names are not just labels. They’re interfaces.

This post is the setup for that idea: why names are messy in human life, why cultures have treated names as power, and why a concept in computer security called object capabilities treats “a name” like a literal key.

Names Are Weird: Falsehoods Programmers Believe

Computers are extremely logical, but human names? Not so much. If you’ve ever designed a system that deals with people’s names, you may have stepped on one of the many landmines hidden in our assumptions about naming.

There’s a famous list by Patrick McKenzie titled “Falsehoods Programmers Believe About Names”, which is basically a hall of fame for many naïve assumptions that will break your code. A few highlights:

• “People have exactly one canonical full name.”

• “People’s names fit within a certain defined amount of space.”

• “People’s names are written in ASCII.”

• “People’s names are globally unique.”

• “People have names.”

The list is funny because it’s true, and it’s true because… we are messy. Names change. People change. Cultures disagree about what counts as a name, which part “goes first,” whether you have a last name, whether the thing you’re writing down is a legal name or a social one, and whether your name even fits into the dropdown the website designer made on a Tuesday afternoon.

The takeaway: names are an identity mirage — we think they’re straightforward strings, but they hide a world of complexity and culture.

Names are often relational, not absolute

As a reminder that “name” can be a relationship rather than a noun: Vietnamese pronouns commonly use kinship terms (e.g., anh/chị/em, cô/chú/dì, etc.) that depend on who is speaking and how you’re related.

And in many families, people are also referred to by birth-order numbers (often discussed in the broader context of Vietnamese names): “the second child,” “the third child,” and so on. In practice these labels are often cemented by first introduction in a family/community context — they’re not private “petnames” in the technical sense, but shared relational handles that make perfect sense to humans and terrible sense to a first_name column.

A “name” like anh (older brother) isn’t identifying you the way a passport does. It’s telling you how I’m positioned relative to you. It’s meaning, not just reference.

Software tends to want the opposite: a stable identifier, globally unique, consistent, and preferably lowercase. Humans respond: “Cute.”

The lesson here? Be careful when you ask for or use someone’s “name” in a system. You might be assuming falsehood #41 without realizing it.

True Names: Ancient Magic and Power Labels

Long before identity thieves and database designers struggled with names, our ancestors were telling tales about the magical power of knowing a name. The idea appears across many cultures: if you know a being’s true name, you can control it.

In myth and folklore, a name isn’t just a label — it’s like having the root password to that person or thing’s soul.

In myth and folklore, a name isn’t just a label — it’s like having the root password to that person or thing’s soul.

For a modern tour of “true name” lore across cultures (with delightful examples), see Tammy Salyer’s “The Magic of True Names”.

You see the pattern everywhere:

• In some Egyptian stories, Isis gains power over Ra by forcing him to reveal his hidden True Name.

• Folk tales like Rumpelstiltskin turn “guess my name” into a life-or-death security challenge.

• Fantasy like Earthsea treats names as the underlying API for reality.

These stories all share the same claim: knowing the right name is a form of access.

What’s interesting is that this is not just poetic. It’s a clean mental model: knowledge of a secret token grants ability to do a thing. That’s basically security.

And then computer science, being computer science, reinvented it with better fonts.

Object Capabilities: When Names Become Keys

Most modern security systems are identity-first. They ask “Who are you?” and then consult an access control list: “Okay, you’re Jas, you may read this file, but not that one.” It’s bouncers and wristbands.

Object capabilities (ocaps for short) flip the question:

Not who are you? but what do you have?

The mantra of capability-based security, coined by Norm Hardy, is: “Don’t separate designation from authority.” Translation: if you can name (designate) a thing in a meaningful, usable way, that naming mechanism often is the authority boundary. So embrace it. Make it explicit.

A capability is an unforgeable reference — a handle — that grants you the ability to interact with some object/resource. If you have the handle, you can use it. If you don’t, you can’t. No global permissions table required.

In the capability model, knowing the name of something is the power to use it.

Car keys (aka best successful capability demo)

A car key doesn’t ask you who you are. It doesn’t care if you’re the owner, the owner’s cousin, or a raccoon with ambitions. It checks one thing:

Do you have the key?

If yes: engine starts. If no: enjoy your walk.

That’s a capability.

This is also why “name” is not the right everyday word in security discussions. Because we hear “name” and think “label.” Capabilities are closer to “handles that unlock something.”

Secret URLs and “names that grant access”

Now take the web’s most popular accidental capability system: the share link.

You create a secret, unguessable URL to a document. Anyone who has the link can view it. Maybe edit it. That URL is a handle that carries authority by possession.

In capability terms, those are often called capability URLs.

A more old-school capability implementation happens to be a YURL: a URL that is intentionally hard to guess and whose possession is what grants you access. It’s “security by unguessability,” except said in a way that doesn’t make your security friends faint.

There are caveats (I am over simplifying a lot of things here!) but the core idea is powerful and surprisingly practical: delegation becomes trivial. Want someone to access the thing? Give them the handle.

Two secret URLs to the same thing can mean different …things

Here’s a subtle part that ties back to relational human names.

Two different secret URLs can point at the same underlying document and still mean different things.

They might encode different permissions (view vs edit), different lifetimes, different audiences (“this link is for my team” vs “this link is for my accountant”), or simply different sharing paths that you want to keep separable for auditing and later revocation.

Even if two links grant identical access today, they can still be distinct handles with distinct meaning.

That’s the web version of calling the same person “Mom,” “Dr. Nguyen,” or “Hey you”: same referent, different relationship, different implied power. Multiple names for one thing isn’t a bug; it’s how humans (and good security designs) express context.

The name you give something is not the name of the thing — it’s how you came to know the thing.

Zooko’s Triangle

If naming still feels slippery, here’s a classic distributed-systems trilemma: Zooko’s Triangle.

Global naming systems want three properties, but (in general) you only get two at once:

• Human-meaningful (memorable: jas.example)

• Decentralized (no single naming authority you must trust)

• Secure (hard to spoof; the name reliably binds to the right thing)

DNS is human-meaningful, but its security depends on a stack of governance and trust. Cryptographic identifiers can be secure and decentralized, but they’re not human-meaningful unless you’re the kind of person who memorizes SHA-256 hashes for fun. (No judgment. Slight judgment.)

Capability systems are oddly content living in the secure + decentralized corner: the handle is deliberately hard to guess/forge, and authority flows by explicit delegation.

The human-friendly part usually lives one layer up: you keep a local alias book — a “petname” system — mapping your memorable names to those unguessable handles. Marc Stiegler’s intro to petname systems is a great place to start if you haven’t seen that framing.

This is another way names become relational: a petname is meaningful to you, in your context, rather than pretending to be universal truth.

Closing

Names are weird in people-land, powerful in myth-land, and in capability-land they’re part of the security boundary. That’s the through-line: the moment a “name” becomes a handle you can pass around, it stops being mere labeling and starts shaping what’s possible.

In the capability model, knowing the name of something is the power to use it.

And maybe that’s the most useful mental shift: treat names like interfaces, not décor. Ask what assumptions they embed. Ask what they grant. Ask what they mean — to humans, to systems, and to whoever is holding the handle.

Names are weird, wonderful, and occasionally a little overdramatic — like they’re auditioning for a YA fantasy novel and a schema migration at the same time.

Names Are Handles was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

If part one was the theory, this one is wizardry.

And yes: this post is going to be very Hogwarts-focused, partly because Hogwarts is weirdly good for threat modeling, and partly because I am a fan of epic stories. (heh — expect a post on probability in Mahabharat at some point). I try to give you a little background but if you don’t know the story, it might be a little difficult!

Once you start looking for security patterns in Harry Potter, they’re everywhere. Names act like handles. Secrets act like access tokens. Identity checks fail in extremely dramatic ways. Delegation works right up until it doesn’t.

So this is less “serious taxonomy of magical law” and more “let’s use a beloved fantasy universe as a security whiteboard.”

Hogwarts (and the wider wizarding world) turns out to be a fantastic case study — with excellent examples, terrible operational hygiene, and an incident response program that mostly seems to consist of panic, headmasters, and vibes.

Hermione Granger is the closest thing the series has to a resident security engineer: policy-aware, constantly threat-modeling, willing to use safeguards, and usually the first person in the room asking, “Okay, but what if this goes wrong?”

Patroling: Gringotts, the Trace and “Something’s Off”

Before we get to identity and capabilities, start with the broadest kind of defense: patrolling / detection systems.

These systems do not primarily answer “who are you?” or “what are you allowed to do?” They answer a fuzzier but still useful question:

“Did something suspicious just happen?”

That’s a real and important category in security: tripwires, anomaly detection, scanners, checkpoints, alerts, and “this looks weird” machinery.

Hermione is a good guide here because she tends to treat alerts as inputs, not conclusions. She notices signals, but she keeps reasoning.

Gringotts & Thief’s Downfall: Security checkpoints

For non–Harry Potter readers: Gringotts is the wizarding bank, and getting deep inside it involves passing through a series of magical defenses designed to catch thieves, impostors, and people attempting enchantment-based tricks.

A great example is Thief’s Downfall in Gringotts: a magical waterfall that strips away concealment and enchantments.

As fantasy, it rules. As security design, it’s basically: run everyone through a de-obfuscation checkpoint and see what falls off.

That’s not identity proof. That’s not capability delegation. It’s patrolling.

And that’s fine. Lots of real systems work like this:

• suspicious-login challenges,

• malware scanning,

• attachment filtering,

• WAF rules,

• anomaly detection.

You’re not proving truth so much as forcing hidden state into the open.

The Trace: detection is not attribution

Quick background: the Trace is a magical monitoring mechanism placed on underage witches and wizards so the Ministry can detect (some) magic happening around them.

The Ministry’s Trace (underage magic monitoring) is another patroling-style system.

It can often detect that magic happened in the vicinity of an underage wizard. But detection and attribution are different problems. The Trace is useful for policy enforcement, but fuzzy about who actually cast the spell.

That maps neatly to modern telemetry: you often know something happened before you know who did it.

You often know something happened before you know who did it.

Wizarding systems repeatedly run into this distinction, and so do real ones.

Dark Detectors & Noisy Reality

In the books, Dark Detectors are magical objects used to warn about danger or deception — think wizard versions of security alarms, except with more brass and more false positives.

Dark Detectors like Sneakoscopes behave like noisy intrusion detection systems: imperfect, occasionally ignored, and often right in the annoying way.

These tools are not a foundation for trust. They are a layer that helps you notice when trust may have been misplaced.

Patrolling systems are useful because they surface anomalies and buy time. But they are not a complete authorization model.

They tell you: something is wrong. They do not automatically tell you: this person should (or should not) have access.

Names as Tracking: Voldemort’s Taboo

Background for the non-fandom crowd: later in the series, Voldemort’s name is literally enchanted so that saying it can reveal the speaker’s location to his forces.

There’s also a nasty hybrid in this category: the Taboo on Voldemort’s name.

For most of the series, people avoid saying “Voldemort” and use “You-Know-Who” instead. Dumbledore pushes against that habit, arguing that fear of the name strengthens fear of the thing.

Then the final book weaponizes the naming behavior itself: say the name, and you’re no longer just speaking — you’re broadcasting.

That’s a wonderfully nasty design because it piggybacks on social behavior. The set of people willing to say “Voldemort” out loud is already a pretty good filter for “people we care about finding.”

So the name stops being a mere identifier and becomes a signal.

That’s one version of name-power: not “knowing the name lets you control the thing,” but “using the name exposes you to the system watching for it.”

In modern terms, it’s somewhere between a keyword trigger, a beacon, and a cursed analytics event.

Hermione also serves as a nice counterpoint here: she starts from books and rules, but she adapts fast when the environment changes. In security terms, she’s not just compliant; she’s situationally aware — which is exactly what you want when the adversary has turned a word into telemetry.

Identity-Like Systems: Polyjuice Problem of Proxies

Patrolling is useful, but it’s broad and noisy. The next step up is more specific: identity-based systems.

Now the system is trying to answer a stronger question: who is this?

That can be more powerful than pure detection — but it’s also where Harry Potter repeatedly demonstrates how fragile identity proxies can be.

One reason the Fidelius is so interesting (we’ll get there) is that it operates on possession of a secret rather than just identity. That stands out in a world where identity checks are constantly being fooled.

And wow, are they constantly being fooled.

The key story mechanic here is Polyjuice Potion: a potion that lets one person temporarily take on the physical appearance of another.

The headline example is Polyjuice Potion, which turns appearance — one of the most common “identity signals” — into a highly unreliable input. If your system is basically “looks like Bob, must be Bob,” then congratulations, your threat model has been defeated by a hair sample.

Polyjuice powers some of the biggest security failures in the series, including the fake Moody situation, which is roughly the magical equivalent of “we gave admin to the attacker and then asked him to run the annual safety training.”

This is the general problem with identity-first systems: identity is often inferred from proxies (face, voice, behavior, papers, uniforms, vibes), and proxies can be forged, stolen, or manipulated.

Wizarding systems repeatedly rediscover this the hard way.

Hermione’s strength in this landscape is that she rarely mistakes a signal for ground truth. She’ll use identity cues, sure — but she also cross-checks, watches behavior, and updates her model when facts change. In other words: she debugs reality.

In other words: Hermione debugs reality.

Magical countermeasures

The books also sprinkle in a bunch of magical “verification” tools and defenses, each useful in some situations and very incomplete in others.

The series also gives us a fun grab bag of countermeasures:

• The Marauder’s Map can reveal who someone really is in some circumstances — basically a “true identity” diagnostic, if someone checks it in time.

• Thief’s Downfall in Gringotts strips magical concealment, which is a very wizard solution to verification: “what if authentication was a waterfall?”

• Dark Detectors like Sneakoscopes behave like noisy intrusion detection systems: not perfect, but useful when something feels off.

• The Ministry’s Trace (underage magic monitoring) is a reminder that detection and attribution are different problems. You can detect that magic happened without always knowing who really did it.

The pattern is familiar to anyone who has worked in security: identity is useful, but brittle. Detection helps, but it’s noisy. Enforcement exists, but attribution is messy. The wizarding world is basically one long postmortem with capes.

Capability-Like Systems: Fidelius as a Strong Model

If patrolling systems are broad and identity systems are more specific-but-spoofable, the Fidelius Charm gives us the cleanest model in this set: possession of a secret handle grants access.

In that sense, it’s the strongest of the three models here — not because it’s magic-perfect, but because the authority boundary is clearer.

The Fidelius Charm: A Secret as a Capability

For context: the Fidelius Charm is a spell that hides a secret (often a location) inside a chosen person called the Secret Keeper, and others can only learn that secret if it is deliberately revealed to them.

If the Taboo shows names as tracking, the Fidelius shows names (or more precisely, secrets) as access handles.

The Fidelius hides a secret inside a person — the Secret Keeper — such that the protected information cannot be discovered unless the Secret Keeper reveals it. The classic example is the location of a house.

That is extremely capability-shaped.

Why? Because access depends less on “who are you?” and more on “do you have the secret?” If you have the handle, you can act. If you don’t, you can’t. You can be standing right there and still be locked out.

Voldemort could have perfect motivation, unlimited malice, and very strong cheekbones, and he’d still be stuck if he doesn’t have the secret.

That’s the key pattern: knowledge of a specific token/secret grants access.

Highlight: Knowledge of a specific token/secret grants access.

In ocap language, this looks a lot like passing around authority directly instead of checking a giant central list of who is allowed to know what. (Which, to be fair, the Ministry would absolutely implement, and it would absolutely run on parchment.)

Why this is stronger

The progression looks like this:

• Patrolling says: “we noticed something.”

• Identity says: “we think this is Bob.”

• Capability-like/Fidelius says: “you have the thing that grants access.”

That doesn’t make Fidelius invincible. It does make the control surface clearer.

In security design, clarity is underrated.

Fidelius and Delegation: Powerful, Useful, Human

In the backstory, James and Lily Potter use the Fidelius Charm for protection during the war, and the choice of who holds that secret becomes one of the most consequential trust decisions in the series.

It’s tempting to read the Fidelius as “wow, secrets are fragile, never share anything, trust no one, move to a cave.” But the more useful lesson is subtler: delegation is necessary, and therefore the question is how you design for it.

The Fidelius is powerful precisely because it lets authority be concentrated and then intentionally shared. That’s not a bug. That’s the feature.

The Potters’ tragedy comes from choosing Peter Pettigrew as Secret Keeper. He doesn’t “hack” the charm. He uses the authority he legitimately has and betrays them.

That’s not really a failure of the capability idea. It’s the oldest security problem on earth: trusted party turns out to be… not a great pick.

In other words: the charm worked. The humans didn’t.

The charm worked. The humans didn’t.

And that distinction matters, because otherwise we learn the wrong lesson. The lesson is not “delegation is bad.” The lesson is “delegation is powerful, so choose delegates carefully and scope authority where possible.”

Which is, coincidentally, also good advice for production access.

This is also where Hermione’s instincts shine as a contrast class. She tends to think in terms of blast radius, contingencies, and who should know what. She’s not anti-sharing; she’s anti-sloppy-sharing, which is a much more useful trait in both magic and engineering.

Grimmauld Place and the Cost of Sharing

Grimmauld Place is the Order of the Phoenix’s hidden headquarters, so it’s a nice example of what happens when a secret location must be shared with a whole working group instead of just one or two people.

The Order’s use of the Fidelius for 12 Grimmauld Place is a more practical example: lots of people need access, which means the secret needs to be shared more widely.

That makes the system more usable. It also creates more ways the secret can spread.

Again, this isn’t doom; it’s a tradeoff. A system that nobody can use is “secure” in the way a brick is a laptop.

As the circle of people with access grows, so does the importance of secondary protections, behavioral discipline, and damage containment. Mad-Eye’s Tongue-Tying Curse on the house is a nice example of layered defense: if the secret is valuable, you don’t rely on a single line of protection and then call it a day.

(If only wizarding Britain also believed in backups.)

Hermione’s choices around secrecy and movement in the later books often read like someone actively managing risk under pressure: imperfect information, bad options, and a constant need to trade convenience for safety. That’s not paranoia; that’s operations.

Names, Handles, and Accidental Delegation

One of the trickiest parts of capability-like systems is that passing authority around is incredibly convenient — which is why we do it — but sometimes you pass it farther than you meant to.

That’s the “oops” version of delegation.

A lot of the Harry Potter examples are dramatic because the stories make authority transfers visible: spoken secrets, magical boundaries, disguised identities, invitations, escorts. In software, we do the same thing with links, tokens, session cookies, API keys, and shared folders… just with fewer owls.

The useful mental model here isn’t “never share.” It’s:

• know what the handle grants,

• know who you’re giving it to,

• and know what happens if it spreads.

That’s true whether the handle is a secret address, a cloud link, a bearer token, or directions to a house hidden by ancient charmwork.

Why This Matters Outside Hogwarts

The point of dragging Harry Potter into a security discussion (besides fun) is that fantasy often makes hidden assumptions visible.

In everyday software, identity, naming, and authority get mashed together so often that we stop noticing the seams. But the seams matter.

• A name can be a label.

• A name can be a signal.

• A name can be a secret.

• A name can be a handle.

• A name can be a story about how you came to know the thing.

Those are different jobs, and systems get weird when we pretend they’re the same job.

Hermione is a useful mascot for this distinction because she’s one of the few characters who consistently separates the question “what is this called?” from “what does this let someone do?” That mental split is half the battle in secure system design. Funny enough, capability systems go out of their way not to make that distinction.

The wizarding examples are useful because they exaggerate the mechanics:

1. Patroling / detection: systems can surface suspicious activity without proving identity (Thief’s Downfall, Trace, Sneakoscopes).

2. Identity: appearances and other proxies can lie (Polyjuice Potion).

3. Capability-like authority: possessing a secret/handle can grant access (Fidelius Charm).

4. Tracking by naming behavior: saying a name can itself become telemetry (Taboo).

5. Delegation: groups function by sharing handles, and mistakes propagate the same way.

That’s not just magic. That’s systems.

Closing

If the first post’s punchline was “treat names like interfaces, not décor,” this one adds a sequel line:

Treat identity with suspicion, and treat delegation as a first-class design problem.

Highlight: Treat identity with suspicion, and treat delegation as a first-class design problem.

Because the world runs on layers: patroling systems that catch weirdness, identity systems that guess who, and capability-like handles that decide who can actually do what. And underneath all of them are passed handles — keys, links, introductions, credentials, invitations, and yes, sometimes whispered secrets.

And if your security model can survive a wizard with a stolen hair, a cursed word, and a flair for theatrical entrances — while still making sense to the Hermione on your team — it’s probably in pretty good shape.

Hogwarts: Names & Delegation was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

I had this romantic idea of university.

The version in my head looked like a Vienna coffeehouse — the late 19th-century “Vienna 1900” scene through the interwar years, roughly the 1880s–1910s and then again 1918–1938. Small tables, big sentences, and people who can argue about infinity and the proper thickness of foam on an espresso.

Vienna’s coffeehouses were where you rented a chair for the price of a cup and then tried to outthink the person at the next table. Newspapers everywhere. Philosophers wandering in like it’s normal. Mathematicians doing that thing where their eyes go slightly unfocused because they’re mentally rearranging the universe.

Cafés cycled as hubs — Griensteidl, then Central, then Herrenhof — and the pattern stayed the same. Public rooms where writers, artists, and philosophers could turn talk into a day job.

In my head, Gödel ideas began as a vibe. Someone says something that shouldn’t be true, and he can’t go home until it either becomes true or he destroys it.

That’s not totally fantasy. There’s a well-known anecdote that in 1930 he first talked through his incompleteness result with colleagues at a Viennese café, Café Reichsrat. A theorem debuting over coffee. Very on brand.

And because it’s Vienna, it’s never just logic. It’s also art.

Klimt makes geometry seductive. Schiele makes the human body look like an uncomfortable theorem. Somewhere in there is the idea that beauty is a kind of evidence — or at least, a persuasive witness.

I wanted college to feel like that. Like ideas were alive.

Reader, it did not.

At university we got close in a small ritual. A group of us would sit around and read sketches out loud from A Bit of Fry & Laurie — the kind of comedy that treats the English language like a trampoline.

That was Trudy’s fault. Trudy introduced me to Fry and Laurie. She’s now a professor of French at the University of Auckland, which feels exactly right — a life devoted to language, with a side hobby of making it do backflips.

Just a bunch of sleep-deprived students doing verbal gymnastics for each other sans costumes and a stage. Timing, cadence, the joy of a sentence that turns a corner and somehow sticks the landing — those were some of my happiest days.

Vienna it wasn’t. Still, it had the essential ingredient. People gathered around language, using it as a way to think in public.

That combination — silliness with a hidden blade of cleverness — stuck with me. It became my template for what “serious” conversation could feel like when it wasn’t trying to prove it deserved to exist.

So, naturally, I tried to host it in my grad-student apartment. Then in the tiny little apartment i had when i had my first job in California.

Last week — this is years later, you realize (sigh: autocorrect wants it to be tears later!) — I ran into Jon Bird, a friend I used to hang out with at university. He too is a professor now — it was that kind of group. We have a friendship you can resume mid-sentence. We started swapping stories and I realized, with mild surprise, that we did get a version of the café myth once.

It came back in fragments. The smell of cheap tea in chipped cups — I stayed in a hostel called Grafton. Our “chairs in a circle” arrangement that always looked like a support group for overthinkers. The accidental hush when someone said something genuinely interesting and then some dirty pun.

It didn’t happen often, which is probably why it stuck. A night in my apartment when someone asked a question that has lived rent-free in my head ever since.

So… what’s special about meat?

It hit the table like a joke, then refused to stay a joke. What makes meat as the medium on which thinking happens so special that silicon would be inferior.

Calvin would have treated that like a homework problem from the universe. Hobbes would have treated it like a warning label.

Grad-student Lighting Vienna Café

I was a starting working life — so if you’re picturing a grad student in an apartment with shoebox acoustics and peak IKEA-on-a-budget energy — you’re doing it right.

Still, I set it up like a salon. Chairs in a circle. Drinks on the table. A loose “don’t win by being loud” rule. The spiritual promise that if you came over, you might leave with a new obsession.

I even had my own version of the café newspaper pile — not actual newspapers (I’m not a monster), but a scatter of half-read books and printouts that made the place look like ideas had recently fought here.

And on the coffee table, Calvin and Hobbes collections. Which sounds like décor until you remember those comics are basically philosophy disguised as snowmen.

If you somehow missed Calvin and Hobbes, it was Bill Watterson’s daily strip about a six-year-old and his tiger. To everyone else the tiger is a stuffed animal; to Calvin he’s vividly alive. It ran from 1985 to 1995, got wildly beloved, and then Watterson ended it on purpose — which is still the most disciplined thing an artist has ever done.

The names are a nerd joke …well with teeth. Calvin is named after John Calvin. Hobbes is named after Thomas Hobbes. Watterson flips it in the best way: comic Calvin isn’t discipline; he’s a tiny chaos engine with metaphysical questions. Comic Hobbes isn’t a stern Leviathan; he’s a skeptical companion who understands that civilization is a thin veneer — and still chooses to be kind.

So on my coffee table, those books were a permission slip: you can be silly and talk about what it means to be a person.

The guest list rotated, but the goal didn’t. I wanted my little apartment to be the place where someone said the sentence that ruined your week (because now you had to go think).

Most nights were… let’s say disappointing but aspirational.

You learn quickly that the hardest part of recreating a Vienna coffeehouse is not the espresso. It’s getting people to stop doing conversational LinkedIn.

Also, I should mention that one night someone lit the carpet on fire.

By accident.

Then there was a night where we were on fire. Metaphorically.

To be continued

I didn’t realize I was building toward that single night — the one where the conversation stopped being silly season and for a moment went scary smart.

Part 2 is that night.

It starts with one word — AI — and then the room split into tribes. The jocks think they’re immune. The engineers want to give machines property rights. The policy students reach for the ban-hammer.

There’s that line about meat that still makes my brain itch. There’s a detour through slavery that nobody enjoyed. There’s a nuclear analogy that works perfectly right up until it doesn’t.

If Part 1 was me trying to recreate a Vienna café, Part 2 is the moment the café finally showed up… and immediately started an argument.

Gödel, Escher, Me — Part 1: The Coffeehouse I Tried to Host was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

or I ≠ U

The sequel to Quines

Previously, we have played with Quines: programs that print their own source code. Self-reproduction. Little computational ouroboros. A charming party trick, like juggling — but for people who think parentheses are a personality.

This time I want the spicier cousin: not “can I copy myself?” but “can I recognize myself?” Same self-reference energy, but with more side-eye.

Origin story: “I neq U”

I’ve been using the name Inequ since 2005 — short for “I neq U” (and yes, also an anagram of quine, because I am incapable of leaving a good pun alone). In that original post, I framed self-recognition as “the ability to tell if I am different (not equal) to you,” then defined an Inequ as a program that reads text from stdin and exits 0 only if it recognizes that text as the same as itself.

A Quine says say me. An Inequ says see me.

Identity by paperwork

The strictest Inequ is hilariously bureaucratic. You paste some program text into stdin. It compares that text to its own source text. If every character matches — same bytes, same newlines, same everything — it says “yes” (exit 0). Otherwise it says “no” (non-zero), as if you showed up at the airport with a boarding pass that says “Jas?” and expected vibes to carry you through.

This version is shallow, but in a very honest way. It’s the computational equivalent of recognizing yourself only in one specific passport photo: same angle, same lighting, same haunted look in the eyes.

And honestly? That’s already a pretty good mirror.

The mirror test, but for code

We like to imagine “self-recognition” is deep and philosophical. But in real life, it starts out embarrassingly literal. Babies don’t pop out passing the mirror test. They see the mirror and think: hello, other baby; we should either become friends or start a rivalry.

Then, eventually, something clicks: the reflection is tethered to their body and actions. “That’s me” becomes a stable concept, not just a visual coincidence.

The strict Inequ is basically at the toddler stage. It doesn’t recognize itself across transformations. It recognizes itself in one very specific mirror, under perfect conditions, wearing the same outfit, with the same lint on the sweater.

And naturally, we immediately demand more.

“But what if it’s still me… with a haircut?”

The first upgrade people ask for is harmless: could it ignore whitespace? Comments? Line endings? Could it recognize itself after someone prettified it, or after a formatter did what formatters do: destroy your identity in the name of consistency?

This is where the definition of “self” starts doing work. Are you your exact text, or your structure? If you parse both programs into an abstract syntax tree (AST) and compare those, you’ve built an Inequ that can survive cosmetic changes. Congrats: your program can now recognize itself in candid photos.

Then you go one step further and ask the question that sounds reasonable until it ruins your weekend:

What if the input program is different text but the same meaning? Same behavior, different implementation. Same person, different life choices.

Now you’ve crossed the line from “string equals string” into “what does this code do?”

Welcome to the part where computer science becomes less like a clever puzzle and more like a stern cosmic boundary marker.

Rice’s Theorem: the universe’s terms of service

There’s a famous result in computability called Rice’s Theorem. Roughly: any non-trivial general question about what arbitrary programs mean is undecidable.

So the dream Inequ — the one that recognizes itself through refactors, rewrites, and alternate implementations — runs into a wall that isn’t made of poor engineering. It’s made of math. This isn’t “hard like chess is hard.” It’s “hard like you can’t make a square circle.”

It’s “hard like you can’t make a square circle.”

You can absolutely do practical versions in restricted worlds: normalization, canonicalization, testing, proof systems for specific languages, all that good stuff. But the universal “are we the same in meaning?” detector for arbitrary programs is the kind of thing the universe declines to provide on principle.

Which is both annoying and, weirdly, comforting. Even code gets to have limits to self-knowledge.

The tiny sandbox: a self-recognizing regex

My favorite side quest (from that same original thread) is the regex version: can you write a regular expression that matches only itself?

Not “a regex that matches the letter ‘a’ and therefore matches the string ‘a’.”

(By the way, if you think I did not delibrately construct that sentence so I had to have nested quotes, you don’t know me!)

That’s too easy and also matches half your inbox. I mean a regex whose accepted language is basically: just me, myself, and I.

If your regex is too loose, it matches itself… and a bunch of other strings. That’s the “I contain multitudes” identity phase where your definition of “me” is so broad that everyone qualifies.

If your regex is too strict, it excludes itself. That’s the “I have standards” identity phase where you define yourself so precisely you accidentally legislate yourself out of existence.

It’s a perfect miniature of the main problem: self-recognition depends on what differences you’re willing to ignore, and the moment you formalize that, edge cases appear like they were invited.

What does it mean to recognize yourself?

Here’s the part I can’t stop thinking about: self-recognition is not a single question; it’s a stack.

At the bottom: exact textual identity. Crisp, brittle, often useful.

Higher up: structural identity. Ignore formatting and cosmetics. Now you can survive a haircut.

Higher still: semantic identity. Meaning, behavior, equivalence. The grown-up version of “me.” And that’s where theory taps the sign: no universal oracles beyond this point.

“The moment you ask for ‘same meaning,’ computer science quietly takes your hope and puts it in a drawer.”

So when we ask “can a program recognize itself?” we’re really asking: which transformations preserve identity? Which changes don’t count as “becoming someone else”? And the moment you say that out loud, it stops sounding like a programming trick and starts sounding like… a human problem.

Takeaway: identity is compression

Identity is a compression scheme. To recognize yourself, you compress messy, high-resolution reality into a signature you can compare. You pick invariants. You decide what can change without changing “you.”

Quines are self-portraiture: here is me.

Inequ is self-concept: I can tell me from not-me.

And the punchline is that the more human you want that second statement to be, the more the universe reminds you: self-knowledge isn’t free — not for toddlers, not for monkeys, and not for programs.

Question for the comments

If you were designing an Inequ, what would you allow it to ignore before it stops being “you”? Formatting? Comments? Variable names? Refactors? Whole rewrites?

And at what point does “same program” become “same vibes” — and do we ship vibes to production? Is it easy to characterize the largest set of inequ?

I Am Not U was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a Station of the Metro with Perl and Unicode

Last week I argued that translation isn’t moving words from one language to another — it’s swapping interpreters, and admitting you can’t keep everything, so you choose what to save and call it “faithful.”

You can’t keep everything, so you choose what to save and call it ‘faithful.’

This week I’m stress-testing that claim on a poem that barely contains any words in the first place: Ezra Pound’s In a Station of the Metro — translated into Perl, using Unicode emoji. Because of course.

That’s not just me being unserious (though I am), it’s me being faithful. The poem is Imagism at peak compression: no narration, minimal grammar, two images placed side-by-side, and the reader does the electrical work in the gap.

Emoji are modern pocket-ideograms: tiny pictures that mean by being seen, not conjugated. If Pound wanted English to behave more like ideographic collage, Unicode is basically his afterlife interface.

Meaning happens in the reader

The poem is famously short, but the title does a disproportionate amount of labor. “In a Station of the Metro” is not a label; it’s the frame. It pins the images to fluorescent modernity: underground, crowded, fast. Without it, you get “faces” and “petals” floating in the abstract. With it, you get a specific kind of fleeting perception — faces glimpsed, then gone.

The poem is less a statement than a circuit: two terminals, and your mind completes the connection.

Then Pound refuses to say “like.” That’s the whole daring. The poem doesn’t announce metaphor; it places two images and lets your mind supply the connective tissue.

That’s also why it feels haiku-ish without being a formal haiku: one instant, a sharp cut, two images in tension, and the spark happens off-page — in you.

Here’s the original:

In a Station of the Metro

Ezra Pound

1885 — 1972

The apparition of these faces in the crowd;

Petals on a wet, black bough.

A quick note on declarative thinking

This is why declarative programming languages feel oddly adjacent to Imagism. Prolog wants facts plus inference. Haskell wants expressions plus types (titles are basically type annotations for poems). Coq wants constraints plus proof.

Pound’s poem is almost declarative: here are the images; here is the frame; now infer the relationship. No “do this.” No “therefore.” Just placement.

Which is precisely why translating it into Perl is funny: Perl is happy to be imperative, messy, and operatic. So the challenge becomes: can we make Perl behave like Imagism — image-first, explanation-last?

Poetic code

This is my attempt!

perl -CS -Mutf8 -E '
  sub station{} my $metro = exists
  #, Ezra
  [1885]->[1972];
  
  our @apparitions = map ord, "🌸", "🙈", "🙂";
  do { $faces = pop @apparitions or UNIVERSAL->can("petals");
       yes: $trees = $faces ^= $_ for @apparitions;
       say pack (" U ", $trees) x +@apparitions }
'

A small confession: Pound used 14 words in the poem; this uses more — call it ~20 “word-ish” chunks depending how you count. That mismatch is part of the lesson: programming languages demand a minimum amount of machinery to run. The goal here isn’t to win a word-count contest; it’s to preserve the poem’s method: frame, juxtapose, refuse to explain. And of course you could cheat my making it all a string — but that would be ick!

Why sub station is the title, not a header

In the original, the title is effectively a third line: it sets the scene so the two images don’t drift into generic symbolism. In the Perl version, that anchoring becomes executable. I am very proud of it!

sub station{} doesn’t describe a station; it declares one. Better, it declares an empty station — pure frame, no narration. That’s the Imagist bargain in code: do the minimum scene-setting, then stop talking and start placing images.

And my $metro = exists is the same move again: grammar that almost completes itself, then deliberately doesn’t. A metro that “exists,” fragmentarily, the way the poem’s moment exists — briefly, incompletely, and then it’s gone.

#, Ezra

Ok this is just me being cheeky.

1. It’s author credit, placed where author credit lives in code: a comment.

2. In Perl, # begins a comment… and in American English, # is called “pound.” So #, Ezra is, literally, Pound, Ezra.

3. And yes: there are extra Perl-y nuances about skipping over that line that a true Perl connoisseur will appreciate. I’m leaving that joy unspoiled for the trained reader on purpose.

Dates are executable, which is the point

[1885]->[1972];

This isn’t just biography stapled on. It’s syntactically real: two array references connected by Perl’s arrow operator. The life becomes a relation: birth → death, written as a pointer.

Which matches the poem’s technique: no explanation, just endpoints and a hinge — and your mind fills the gap.

Ahem it helps that it is needed for that dangling “exists” earlier but we don’t need to go into that. Unless you’re a nerdy perl nerd.

The printed trees matter

The poem’s second line gives you a dark structure (bough) that holds brightness (petals). Your code does a version of that by ending not with explanation, but with output: it prints a Unicode character derived from the “apparitions” and repeats it.

That repetition is important. x +@apparitions doesn’t print a single emblem. It prints a cluster. It gives you a little stand of “trees” on the terminal — something structural and dark-ish that the earlier bright images have collapsed into. In other words: the program doesn’t paraphrase the metaphor; it produces an image that plays the same role as the bough.

One last practical note: when you run that one-liner, it does print “trees” to your terminal — a repeated Unicode glyph (the $trees character), printed x +@apparitions times. If you see boxes or tofu instead, it’s not the poem’s fault; it’s your font refusing to believe in forests.

The interpreter prints. The reader interprets.

Try it yourself

Copy/paste the one-liner exactly as-is:

perl -CS -Mutf8 -E '
  sub station{} my $metro = exists
  #, Ezra
  [1885]->[1972];
  our @apparitions = map ord, "🌸", "🙈", "🙂";
  do { $faces = pop @apparitions or UNIVERSAL->can("petals");
       yes: $trees = $faces ^= $_ for @apparitions;
       say pack (" U ", $trees) x +@apparitions }
'

Quick Unicode bureaucracy notes:

• -Mutf8 treats the source code as UTF-8 (so the emoji literals parse correctly).

• -CS makes I/O Unicode-sane (so output isn’t mangled).

• -E enables say and modern conveniences.

If you get boxes instead of trees, your terminal font is doing an anti-Imagist interpretive dance.

What this teaches us about translation

This isn’t just poetry wearing a Perl costume. It’s a reminder that translation isn’t “preserve meaning” like a checksum. Translation is choose what you’re being faithful to.

This isn’t just poetry wearing a Perl costume.

Here, fidelity isn’t literal wording. It’s the poem’s method: context carried by the title, metaphor created by juxtaposition, verbs withheld so the reader performs the final computation internally. The Perl version keeps that bargain: it makes the frame executable, turns biography into syntax, and pushes explanation out of the program and into the reader.

At its best, translation isn’t moving sentences across a border. It’s moving a way of thinking into a new set of rules — and discovering what survives when you’re forced to pick what matters.

I have no doubt you can do this better — I’d love to see it.

Ezra Pounds Forests was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lessons from what it means to translate a nursery rhyme into JavaScript

“Poetry is what gets lost in translation” — Robert Frost

This quote is widely attributed to Robert Frost but the attribution itself is a tiny translation problem: the line has travelled so far it now arrives without its luggage. We don’t know if it was something he said.

Still — misquote or not — the sentiment lands. Something precious tends to leak when you move a poem across languages. But what I like about translation isn’t only the loss. It’s the recovery: what gets found is often stranger, more personal, and — if you lean into it — delightfully alive.

I’m happiest when translation stops pretending it’s a courier service

I’m happiest when translation stops pretending it’s a courier service (“same package, different address”) and admits it’s closer to stage magic: misdirection, trade-offs, and a very intentional choice about what you’re trying to preserve. Sound? Sense? Shape? Mood? The feeling of your mouth doing something ridiculous?

That question gets sharpest with nonsense poems, where meaning isn’t the only tenant in the building. Sometimes it’s not even paying rent.

What does it even mean to “translate” something?

There’s a useful heresy hiding in plain sight: translation is not a single operation. It’s a family of operations that share a vibe.

Charles Simic, speaking about translating poetry, calls it “an act of love” and says, “Translating is like being a medium… one becomes another.” (Simic, 2008)

The point isn’t to be ‘correct.’ The point is to declare what you think is load-bearing.

That’s already a clue. Translation isn’t merely mapping words; it’s mapping experience — and choosing which parts of the experience are load-bearing.

With ordinary text, you can often optimize for meaning and call it a day. With poetry, you’re juggling more than semantics. You’re juggling sound, structure, and effect — tone, surprise, humor, dread, that engineered little click when a line snaps into place. Nonsense poetry is what happens when sound and effect get promoted to lead actors and semantics becomes… a special guest star.

Jabberwocky: when “meaning” is a rumor you heard about

Lewis Carroll’s “Jabberwocky” appears in Through the Looking-Glass (1871) as mirror-writing that Alice has to decode before she can even read it — translation-as-mirror, baked into the story. (Carroll, 1871)

What makes “Jabberwocky” such a brutal test isn’t only the invented words. It’s that the poem still works even when you don’t know what “slithy toves” are. The grammar carries you. The sound carries you. The narrative skeleton carries you. You understand it the way you understand a song lyric you misheard for ten years: incorrectly, confidently, and with feeling.

So what’s the translator meant to preserve? The illusion that the words mean something? The nursery-rhyme momentum? The mouthfeel of “galumphing” and “snicker-snack”? Carroll is basically asking translators: can you rebuild a dream in a different brain? (No pressure.)

Translation as microscope, not photocopier

Douglas Hofstadter’s Le Ton beau de Marot (1997) is a love letter to the idea that translation is less about correctness and more about attention. (Hofstadter, 1997)

He circles a short French poem with translation after translation, using each one like a lens: every version reveals what it values, what it sacrifices, and what it believes a poem is.

That framing is liberating because it turns translation from a verdict (“faithful / unfaithful”) into a catalog of interpretations. If you show your work, you’re allowed to be lopsided on purpose — preserve rhyme at the expense of meaning, preserve meaning at the expense of music, preserve structure as the main event. Nonsense and wordplay force that honesty because they won’t let you pretend there’s a single right mapping.

Mots d’Heures : trolling by sound footnotes

Before you scroll: say this sentence out loud in your best fake-French professor voice, with complete confidence and at least one unnecessary hand gesture.

Un petit d’un petit
S’étonne aux Halles
Un petit d’un petit
Ah! degrés te fallent
Indolent qui ne sort cesse
Indolent qui ne se mène
Qu’importe un petit d’un petit
Tout Gai de Reguennes.

No really — it’s worth it — don’t read forward without reading this out loud…especially…if you don’t speak French.

Luis d’Antin van Rooten’s Mots d’Heures: Gousses is a prank with a philosophy degree. (van Rooten, 1967)

It presents “French” poems with scholarly glosses, but the “French” is actually English nursery rhymes written homophonically — English-to-French by sound, not by sense. You don’t decode it so much as you say it out loud and let your brain snap into place like a misaligned GIF finally animating.

It’s translation-as-ear and translation-as-performance. It’s also a reminder that sometimes the target language isn’t French at all — it’s your auditory cortex.

Haiku: translating with constraints

Here’s my confession: I don’t know a lot of other natural languages well. I dabble. I admire. I borrow phrases like a magpie with good intentions and questionable grammar.

But I do love haiku, and one of my favorite kinds of translation is translating into a constraint system rather than into another language. That still counts. You’re moving expression into a new space and trying to preserve… something.

In English, a haiku is commonly described as 17 syllables arranged 5–7–5. (Britannica, 2025)

But haiku practice also carries stylistic expectations — seasonality, juxtaposition, a little cut or turn. Those aren’t syntax rules; they’re cultural rules. Which is why it maps embarrassingly well onto how programmers talk about style: Python programmers doing the “pythonic” vibe, and Perl coders taking on a “DWIM” attitude — that’s “do what I mean” for those in the know. Tim Peters’ Zen of Python makes this explicit: “Beautiful is better than ugly” and “Readability counts.” (Peters, 2004)

So: what happens if we translate “Humpty Dumpty” into haiku twice — once preserving vibes, once preserving meaning?

Humpty Dumpty → Vibes-first haiku

Egg-moon on the wall

balance, bright hush, holding breath

gravity grins, waits

Sudden white tumble

a joke breaks open midair

silence after snap

Hooves drum, boots clatter

royal fuss in frantic loops

orders fill the air

Hands hover, helpless

magic fails; glue won’t obey

broken stays broken

Humpty Dumpty → Meaning-first haiku

Humpty perched up high

on a wall, calm as a king

before the crash came

Then he slipped and fell

a hard, loud end to the perch

shells scatter below

King sent every hand

horses, men, rushing to mend

a crowd at the wall

Still, nobody could

put the cracked pieces back right

into one again

If you’re reading this on Medium: steal one of these and improve it shamelessly. Better yet, post your own in the comments — either vibes-first or meaning-first. I’ll count that as translation practice and mild public service.

Programs as poems & poems as programs

Now for my favorite kind of translation: the kind where the target language isn’t French or Japanese — it’s JavaScript, or Perl, or even GIF.

Over two decades ago I built polyglots: files that are valid in different programming languages, and even weirder, files that are valid images and valid programs (Nagra, 2001). In this case, it was originally Perl and GIFs and then another with JavaScript and GIFs.

A GIF viewer is basically an interpreter with a peculiar input language; run the same bytes through a different interpreter and you get a different “meaning.”

If you’ve ever seen a JS/GIF polyglot used as a security trick, it’s the same idea wearing a slightly more insidious hat. (Abraham, 2015)

I also have old Perl artifacts floating around CPAN that play in this space — because apparently I cope with reality by turning file formats into bilingual puns.

This is why I’ve always liked WordPress’s slogan “Code is Poetry.” It’s not saying code rhymes. It’s saying code has voice, culture, constraint, and style — the same way poems do.

So let’s do a literal stunt: translate “Humpty Dumpty” into JavaScript in a way that keeps the nursery rhyme’s cadence as syntax.

Humpty Dumpty as a JavaScript chant

Below is the “chant” version: it reads like the rhyme, but it’s a valid JS program that prints each line as you hit ._.

const _=new Proxy({b:[]},{
  get:(t,k)=>k=="_"?(console.log(t.b.join(" ")),t.b=[],_):(t.b.push(k.replace(/[a-z]/gi,c=>c[`to${k?'Upp':'Low'}erCase`](k=!k))),_)
});

_.Humpty.Dumpty.sat.on.a.wall._
_.Humpty.Dumpty.had.a.great.fall._
_.All.the.kings.horses.and.all.the.kings.men._
_.could.not.put.Humpty.Dumpty.together.again._

What’s going on (in the poetic sense, not the JS sense) is that we’ve built a tiny language where property access is word selection, and ._ is the line break. It’s translation by inventing a new reading protocol.

A small humane cheat

I should admit something about that JavaScript “Humpty Dumpty” chant: it cheats. And I dislike it.

The rhyme itself is clean and blunt — wall, fall, horses, men, failure. But the little preamble at the top, the bit of proxy-powered nonsense that makes the rest of the code behave like poetry… that part doesn’t belong to the poem in the same way. It’s scaffolding. It’s stage rigging. It’s the trapdoor under the magician’s hat. I put it there so I could caress the rest of the “code” into a shape that reads like the nursery rhyme.

But really, that’s not just a programmer problem. It’s a translation problem.

Real poets do this all the time, except the scaffolding is cultural instead of syntactic.

Real poets do this all the time, except the scaffolding is cultural instead of syntactic. We carry background into the poem the way a runtime carries libraries. If I write “the Ganges,” some readers just see “a river.” Others feel a whole stack of history, ritual, grief, devotion, politics, and morning light. That’s not in the letters G-a-n-g-e-s; it’s in the interpreter.

So imagine you’re translating a Hindi poem that leans on that name. You’re translating it into French. What do you do? Do you keep “Ganges,” letting it remain a foreign proper noun and hoping the reader brings the right context — or at least goes looking? Or do you “help” by translating it into something locally legible like “the Seine,” because it’s a famous river in a famous French city?

But then: is the Seine a fair substitute? It’s important, yes. It runs through Paris, yes. But does it carry the same religious and civilizational gravity to Parisians that the Ganges carries to people who live on its banks? If not, you’ve preserved the shape (“river in a capital”) and lost the charge.

My JavaScript preamble is basically trying to do for the interpreter (heh!) what translators sometimes do with footnotes, prefaces, and little acts of guided attention: “Hey — before you read this, let me tell you what kind of reader you need to be.” It’s not part of the poem, exactly. It’s part of the translation.

Translation isn’t just moving the text. It’s smuggling an interpreter.

Which is also the most honest thing about it. Translation isn’t just moving the text. It’s smuggling an interpreter.

Can we translate without the scaffolding?

Ok this is all well and good. But is it the best we can do?

In the next week’s version, I want to see how far we can get without that kind of code preamble — whether a poem can be translated into executable syntax with less rigging and fewer stage directions. That means being more honest about constraints: which constraints of the source poem I’m preserving (line breaks, cadence, repetition, punchline timing), and which constraints of the target programming language are non-negotiable (parsing, token boundaries, evaluation rules).

Polyglot thinking is where those two constraint systems collide: sometimes you find an elegant overlap, and sometimes you discover that the interpreter has Opinions. Either way, it’s the fun kind of hard — the kind where even the failures are interesting artifacts.

“Good” translations

A translation is a claim. It claims: these parts I believe matter and this is what I think it says.

That’s why the most honest translations — especially of poetry — aren’t the ones that pretend to be invisible. They’re the ones that admit what they’re faithful to. Simic calls translation “an act of love,” but it’s also an act of decision. (Simic, 2008)

Hofstadter’s whole point is that you can be faithful in many incompatible ways, and the incompatibility is the lesson. (Hofstadter, 1997)

Even Frost’s haunted little aphorism survives because it smuggles a warning: don’t pretend the loss isn’t real.

So yes — poetry gets lost. But sometimes what it gets lost into is new. A new poem entirely.

And if you want a low-stakes way to test that: translate something tiny. Translate it twice. Then post both. Translation isn’t just accuracy. It’s revealing what you think a thing is.

Untranslatable was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are questions we don’t know yet, questions we can’t know ever, and questions where the answer literally can’t fit inside the universe. Knowledge has a storage quota.

I know — that sounds a bit ominous. But as someone who loves asking questions, I find it oddly comforting that the universe still keeps secrets. It means there will always be mysteries left to chase. In this post, I’ll take you on a quick tour of the different kinds of limits on what we can know. We’ll meet unsolved puzzles, deterministic demons, unpredictable butterflies, indecisive cats, mathematical magicians, picky axioms, busy beavers, and a logician who proved math can’t handle all its own truths. Buckle up; it’s a wild ride through the edge of the knowable.

Open Problems: Questions We Don’t Know Yet

Some questions are unanswered simply because nobody has answered them yet. They’re not unanswerable in principle — we just haven’t cracked them. A lot of the time it’s because the problem is underspecified or just really hard. You’ve probably encountered an underspecified question in everyday life. (Ever been asked “Which programming language is the best?” with zero context? Yeah. Good luck answering that definitively.) If a question doesn’t pin down enough details, it can have multiple equally valid answers or no clear answer at all. It’s like asking “How do I get there?” without saying where “there” is — the question is incomplete by itself.

Then there are well-defined questions that are just open problems. These are the famous brain-busters that generations of experts have gnawed on with no success so far. For example, in computer science one of the biggest unsolved questions is “P vs NP” [Cook, 1971]. It asks whether every problem whose solution is easy to verify (that’s NP) is also easy to solve quickly (that’s P). Intuitively, it seems some problems are much harder to solve than to check, but no one has proven it. Similarly, in math, we’ve been stuck for centuries on the Goldbach Conjecture (posed in 1742) which says every even number is the sum of two primes [Goldbach, 1742]. It’s been tested up to ridiculously large numbers and it’s probably true, but a proof remains elusive. These kinds of questions might get solved tomorrow, or next year, or never — we don’t know. The point is, nothing fundamental (so far as we can tell) prevents us from knowing the answer eventually; we just don’t know it yet. It’s a reminder that sometimes the only barrier to knowledge is time, effort, and a lot of creative thinking.

Predictability vs Determinism

Okay, now let’s suppose we do have a well-defined question about a system that follows strict rules. You might think if the world is deterministic (rule-bound and cause-and-effect), we should be able to predict everything given enough data and brainpower. After all, if effect follows cause like clockwork, nothing is truly random, right? In principle, yes. But in practice, not so much. I like to illustrate this with a simple example: imagine tossing a die. The outcome seems random, but physicists will tell you it’s actually determined by the die’s initial position, the force of your throw, air currents, and so on. If you had a super-powered camera and computer, you could in theory calculate how it will land each time. The catch: you’d need ridiculous precision. A tiny change in the initial angle or speed, too small for you to measure, can change the result from a six to a three. So unless you’re an omniscient supercomputer, the die roll is effectively unpredictable for you.

This is a general theme: determinism does not automatically mean predictability for finite mortals like us (or even our best AI).

Determinism is not the same as predictability.

We see this even at astronomical scales. In the 1840s, scientists noticed Uranus wasn’t following its expected orbit; something was tugging on it. Two mathematicians (Urbain Le Verrier in France and John Couch Adams in England) crunched the numbers and predicted a new planet must be out there. Sure enough, Neptune was discovered in 1846 exactly where the math said it’d be — a triumph of determinism and prediction [Le Verrier, 1846]. Yet, ironically, we struggle to predict weather more than a week or two out. It’s not that weather doesn’t follow physical laws — it absolutely does — but it’s so sensitive to tiny details that any uncertainty blows up fast. In short, the universe can be 100% deterministic and still hide the future behind complexity. To know some outcomes, you’d basically have to turn the universe into your personal calculator (which kind of defeats the purpose!).

Laplace’s Demon and the Chaos Butterfly

Let’s talk about an infamous thought experiment in determinism. In 1814, mathematician Pierre-Simon Laplace imagined an intellect so vast that it could know the position and momentum of every particle in the universe at a given instant. If this demon (as it was later called) knew all the laws of physics too, it could, in Laplace’s words, “embrace in a single formula” the entire past and future of the universe — nothing would be uncertain, and it could predict everything that will ever happen [Laplace, 1814]. Essentially, Laplace’s Demon is the ultimate know-it-all, armed with perfect data and infinite computing power.

Sounds neat — but enter the butterfly. In 1963, meteorologist Edward Lorenz discovered something both fascinating and troubling while running weather simulations. He found that extremely small changes in starting conditions led to wildly different outcomes. In one anecdote, he rounded a number ever so slightly in his model, and the “forecast” diverged completely from the original after a while. He later popularized this as the Butterfly Effect: the poetic idea that a butterfly flapping its wings in Brazil could set off a tornado in Texas through a chain of subtle influences [Lorenz, 1963]. This was the birth of chaos theory in classical physics. It told us that even if the world is deterministic, tiny uncertainties in our knowledge can explode into big uncertainties in our predictions.

Chaos doesn’t break the laws — it weaponizes tiny measurement errors.

In real life, no measurement is perfect. You can’t know every decimal of every particle’s position and speed. There’s always a little rounding error or unknown detail. Chaos theory says those teeny unknowns can amplify until your prediction is nonsense. So Laplace’s poor demon, clutching its cosmic clipboard of initial data, could still get the future disastrously wrong because it missed a butterfly flapping somewhere. This is why we’ll never have a perfect weather forecast for next month, and why even deterministic systems can keep secrets. Predictability has limits, demon or no demon.

Quantum Indeterminacy: Nature’s Uncertainity

Up to now we’ve talked as if the universe were perfectly deterministic underneath it all. Classical physics kinda works like that. But when we zoom into the subatomic world, the rules get…fuzzy. Quantum mechanics famously introduces indeterminacy — outcomes that are fundamentally random, not just unknown due to lack of info. You’ve probably heard of the Heisenberg Uncertainty Principle, which Werner Heisenberg formulated in 1927. It says you can’t simultaneously know certain pairs of properties (like a particle’s position and momentum) with arbitrary precision — the more precisely you pin down one, the less you know about the other [Heisenberg, 1927]. This isn’t a limitation of our instruments; it’s a limitation of nature. It’s as if the universe says, “you can know this or that, but not both.” At a very basic level, the present can refuse to divulge all the details needed to predict the future.

And it gets weirder. In quantum physics, even if you know everything about a system allowed by Heisenberg’s rule, the outcome of a measurement can still be genuinely random. The poster child here is Schrödinger’s cat. In 1935, Erwin Schrödinger imagined a (hypothetical!) cat sealed in a box with a radioactive atom that has a 50/50 chance to decay and trigger a poison. Quantum theory says until you observe the system, the atom is in a strange superposition of “decayed” and “not decayed,” which by extension means the cat is both alive and dead at the same time. Absurd? Yes, Schrödinger meant it as a critique, but it captures the idea that outcomes aren’t determined until they “collapse” upon measurement [Schrödinger, 1935]. Before we check, nature itself hasn’t decided which way things go — it’s literally playing dice. (Einstein famously grumbled about this in the 1920s: “God does not play dice with the universe,” he wrote. Niels Bohr and colleagues replied, “Stop telling God what to do,” and kept rolling with the randomness.)

Quantum mechanics doesn’t always predict outcomes; it predicts distributions.

Now, there are different interpretations of quantum mechanics that try to make sense of this. The traditional Copenhagen interpretation basically says “just accept the probabilities; when you measure, the wavefunction collapses randomly according to those probabilities, end of story.” But there’s another wild idea from Hugh Everett in 1957: the Many-Worlds Interpretation. Everett suggested that when a quantum event happens, all outcomes occur, but each in a different branch of the universe — effectively spawning parallel universes for each possibility [Everett, 1957]. In Many-Worlds, nothing is truly random; it’s all deterministic, but it deterministically forks into multiple realities. However, from your perspective as an observer, you still can’t know which branch you’ll end up in, so it feels random. Either way, whether reality is fundamentally probabilistic or splitting into zillions of alternate timelines, the practical upshot is the same: there are limits on what we can predict or know. There’s no experiment you can do to get a sneak peek at a quantum outcome before it happens. Nature keeps those cards hidden until the moment of truth, and no Laplace’s Demon can intervene — the demon’s more likely to find itself tangled up with Schrödinger’s cat, shrugging in ignorance.

When Existence Isn’t Enough

Shifting gears from physics to pure mathematics: have you ever read a proof that something exists, but at the end you still have no clue what it is or how to find it? If so, you’ve met a non-constructive proof. These are proofs that show something is true or something exists without giving a concrete example or method. They’re the mathematical equivalent of saying “a treasure exists on this island” but providing no map to find it. In fact, the great mathematician Hermann Weyl quipped in 1946 that non-constructive existence proofs “inform the world that a treasure exists without disclosing its location” [Weyl, 1946]. You know the treasure is definitely there (because if it weren’t, you’d hit a logical contradiction), but you’re left scratching your head about where it is.

I remember the first time I encountered a proof like this — it was both awe-inspiring and frustrating. On one hand, logic somehow guaranteed a result was true; on the other, it gave me zero tools to actually see the truth in action. A classic example: there’s a simple proof that there exist two irrational numbers a and b such that a^b is rational. The proof basically says: take a = √2 and b = √2. We don’t know if aᵇ = √2^√2 is rational or not.

If it is rational, great — we found our pair. If it isn’t rational, then let a = √2^√2 and b = √2; in that case a^b = (√2^√2)^√2 = 2, which is definitely rational. Either way, such a and b exist. Ta-da! We proved it without ever pinning down exactly which case holds. The proof doesn’t tell us whether √2^√2 is rational or irrational (for the record, it’s believed to be irrational, but that’s a non-trivial fact). We got an existence result with no constructive witness.

Why is this a limit to knowledge? Well, if your proof doesn’t provide a way to construct or identify the thing whose existence it guarantees, then knowing that it exists is a very abstract kind of knowledge. It’s like being assured “a solution is out there” but not being able to actually compute or exhibit it. In computer science terms, it’s the difference between knowing a program terminates and actually being able to run it to get a result. Some mathematicians (especially the intuitionists in the early 20th century) were deeply uncomfortable with this. They argued that a proof should ideally show you the thing it’s talking about or at least give a method to find it — otherwise, have you really gained understanding? Constructive proofs do exactly that: if they say something exists, they show you how to build it step by step, or at least outline a procedure. Non-constructive proofs are more like magic tricks: now you see that something is true, but you don’t see how.

Both types of proofs are perfectly valid in standard math, but the non-constructive ones highlight a curious epistemic limit: you can “know” a truth in theory without being able to extract any concrete example or algorithm from that knowledge. It’s a bit of a tease — Mother Nature (or math nature) saying, “Yes, the answer exists, but I’m not telling you what it is!” As a result, we often have to refine our question if we want something actionable. It’s one thing to know some strategy will win a game of chess (in fact, it’s provable that either White can force a win, or Black can, or at least a draw must be forceable — one of those is true by logic), but it’s another thing entirely to know which strategy and actually play the winning moves. Until we can construct the solution, our knowledge, while true, remains tantalizingly incomplete.

Axioms and Assumptions: When the Answer Depends on the Rules

Not all truths are universal; some depend on which axioms or fundamental assumptions you start with. In mathematics, axioms are the basic rules of the game, the things you don’t prove but assume. What’s shocking is that certain statements turn out to be neither provably true nor provably false using a given set of axioms — they’re independent of those axioms. In such cases, if you want an answer, you have to change the rules a bit and adopt new axioms!

A historical example: for two thousand years, people accepted Euclid’s postulates as the foundation of geometry. One of these postulates (the infamous Fifth Postulate) basically says that given a line and a point not on that line, there’s exactly one parallel line you can draw through that point. Mathematicians tried to prove this postulate from the others, suspecting it was more of a theorem than an assumption — but they kept failing. Finally, in the 19th century, folks like Nikolai Lobachevsky and János Bolyai had a radical idea: what if the Fifth Postulate is not true? What if, say, more than one line through that point can be parallel to the given line? They developed entirely self-consistent non-Euclidean geometries on that premise. Lo and behold, these new geometries were just as logical as Euclid’s, but had wild implications (for instance, on a saddle-shaped space you can have infinite “parallel” lines through a point, and the angles of a triangle sum to less than 180°). This showed the parallel postulate wasn’t provable from the others — it was an independent assumption. You could take it or leave it, and geometry would go in different directions accordingly [Lobachevsky, 1829]. The truth of statements like “angles of a triangle sum to 180°” suddenly became conditional: true in one axiom system (Euclidean) and false in another (hyperbolic geometry). Which is the truth? There is no single answer; it depends on your axiom choice, like choosing different rulebooks.

Perhaps an even more striking case in modern math is the Axiom of Choice. This axiom, formulated by Ernst Zermelo in 1904, says roughly that given any collection of disjoint non-empty sets, you can pick exactly one element from each set (even if the collection is infinite) [Zermelo, 1904]. Sounds innocuous, even obvious, right? Well, adopting this axiom has some crazy consequences. With the Axiom of Choice in hand, mathematicians Banach and Tarski proved a 1924 result so counterintuitive it feels like a magic trick: you can take a solid ball, cut it into a finite number of weirdly shaped pieces, and reassemble those pieces to form two solid balls each the size of the original. Yes, you read that correctly — you get two for the price of one, violating volume conservation in a purely mathematical way (don’t try this at home, it only works in abstract math land) [Banach & Tarski, 1924]. The Banach-Tarski Paradox is a byproduct of accepting the Axiom of Choice. If you reject that axiom, such paradoxes don’t occur, but you lose some other nice results.

For a long time, it wasn’t clear if Axiom of Choice was actually a separate assumption or if someone clever would eventually prove it using the other axioms of set theory. This was settled in the 20th century: in 1963, Paul Cohen showed that Axiom of Choice is independent of the standard Zermelo-Fraenkel (ZF) axioms of set theory (building on earlier work by Gödel in 1940). In other words, you can’t prove or refute the Axiom of Choice from ZF; you have to either assume it or not assume it, and neither decision will make your system inconsistent [Cohen, 1963]. The same goes for another famous statement, the Continuum Hypothesis, which conjectures a specific size for the set of real numbers — Gödel and Cohen showed it’s independent of ZF as well.

The takeaway here is mind-bending: there are propositions for which no amount of logical deduction from our current axioms will ever give an answer. The question “is X true or false?” can be met with “well, that depends on which universe of math you’re in — the one where we assume Axiom Y or the one where we don’t.” These limits are not due to human ignorance or lack of trying; they’re built into the logical structure of mathematics. If the axioms don’t decide the issue, then that truth is literally unreachable unless you expand your axiom list. It’s a bit like trying to play a game and realizing a certain scenario can never be resolved because the rules didn’t cover it — you either add a house rule or live with ambiguity.

When Algorithms Hit a Wall: Busy Beavers and Ωmega

We’ve seen physical and logical limits; here’s a computational one. In 1936, Alan Turing proved there’s no general algorithm to solve the “halting problem” for all possible programs [Turing, 1936]. The halting problem asks: given a program and an input, will the program eventually stop or run forever? Turing showed that any supposed universal method to decide this will fail on some program, essentially because you can make programs that cleverly ask “what would the decider say about me?” and then do the opposite. It’s a brilliant proof, and it unveiled a fundamental truth: there are well-defined questions about the behavior of algorithms that are unanswerable by any algorithm. This result puts a cap on computational knowledge — some things no computer (no matter how advanced) can systematically figure out for all cases.

Building on that idea, mathematicians have explored specific unanswerable questions. One famous example is the Busy Beaver problem, introduced by Tibor Radó in 1962 [Radó, 1962]. The setup is actually fun: imagine all possible computer programs of a given size (say programs with n states, if we use the formal model of a Turing machine). Most of these programs either run forever or eventually halt with some output. Among those that halt, some run longer than others before stopping. The busy beaver BB(n) is defined as the maximum number of steps that an n-state program can execute before halting (assuming we only count programs that do halt). So BB(n) is like the Mount Everest of runtimes for programs of size n. The catch? Turing’s undecidability result implies that the busy beaver function grows faster than any computable function — and in fact, BB(n) itself is uncomputable for general n. You can determine a few initial values by brute force and ingenuity (researchers have figured out BB(1) through BB(4), and recently even nailed down BB(5) after decades of effort), but then it takes off into the stratosphere. Each time you increase n, BB(n) gets so astronomically large that it leaves everything else in the dust.

To give you a sense: No one knows the exact value of BB(6), but we have proven some lower bounds. In 2022, busy beaver hunters (yes, that’s a thing!) showed that BB(6) is at least on the order of 10^36,000,000 or more. That is a number with 36 million digits! In fact, it’s so huge that it’s literally impossible to write it out in full in our physical universe — even if you tried to write digits on every atom, you’d run out of atoms long before you finish [Brubaker, 2025]. The exact value of BB(6) could be much larger still, and we may never know it precisely. This is a clear-cut case of an answer that can exist in theory but can’t fit in the universe (as our opening hook teased). It’s not just that we humans can’t compute it — the number is so ridiculously big that the entire universe doesn’t have enough resources to represent it explicitly. And because determining BB(n) in general is tied up with the halting problem, we know no algorithm can crank out all busy beaver values. It’s a provable limit on knowledge: some well-defined numbers will forever evade exact capture.

Related to this is Chaitin’s Ω (Omega), a number Gregory Chaitin defined in 1975 using algorithmic information theory [Chaitin, 1975]. Ω is the probability that a random program will eventually halt. It’s a single real number between 0 and 1, but its binary expansion is chock-full of unknowable bits. You can prove Omega is a perfectly well-defined number, but you can also prove that its digits are uncomputable and even unprovable beyond a certain point. Each bit of Ω is like a true/false answer to some specific halting problem. If you could somehow obtain the first N bits of Ω, you’d effectively solve all halting problems for programs up to a certain size N. But Turing tells us we can’t have a general method for that, so the bits of Ω are fundamentally unknowable by any finite means. In fact, for any given axiomatic system (any formal theory of mathematics you might choose), there’s a limit to how many bits of Ω that system can determine for sure — beyond that, Ω’s bits are independent of the axioms (this is a result Chaitin derived, connecting to Gödel’s incompleteness). In plainer language, Ω is a number that contains infinitely many true mathematical facts that can never be proven within any fixed system. Talk about a locked vault of secrets!

Some answers exist in theory but don’t fit in the universe.

All this shows that even in the realm of computing and math, we hit hard ceilings. There are functions that outgrow not just our brain but any conceivable method. There are truths encoded in numbers that no amount of computation or theorem-proving can dig out. It’s both humbling and kind of beautiful. We’ve essentially found the spots in the landscape of knowledge marked “Here Be Dragons” — regions forever beyond algorithmic exploration.

Gödel’s Incompleteness: The Unprovable Truths

Our final stop is one of the most profound limitative results in intellectual history. In 1931, Austrian logician Kurt Gödel published a paper that shook the foundations of mathematics and logic [Gödel, 1931]. He proved the famous Incompleteness Theorems. The first incompleteness theorem, in rough terms, says: any sufficiently powerful and consistent formal system (essentially, any axiomatic system capable of doing basic arithmetic) will contain true statements that it cannot prove. In other words, if your axioms and rules of inference are consistent (they don’t lead to contradictions) and strong enough to describe the integers, then there will always be propositions about those integers that are true but that elude proof within the system.

Gödel’s method was ingenious and built on a self-referential trick. He constructed a statement in the language of the system that essentially says, “I am not provable in this system.” It’s like a mathematical version of the liar paradox (“this sentence is false”), but crafted with rigorous arithmetic coding. If the system could prove that statement, it would be proving a falsehood (since the statement asserts it’s unprovable), which would make the system inconsistent. So if the system is consistent, it cannot prove the statement. But if the system cannot prove it, then the statement is true (because that’s exactly what it claimed). Thus, the system has a true statement it cannot prove. Mic drop. Gödel showed not just one such statement, but an infinite family of them, lurking in any axiomatic theory that’s rich enough. His second incompleteness theorem added more spice: it said no such system can prove its own consistency either (assuming it is consistent). So you can’t even have a system that neatly says “I am consistent” unless it actually isn’t (in which case it could mistakenly prove that and everything else).

What does this mean for knowledge? It means that logic itself places a fundamental limit on formal knowledge systems. Even if you have an infinite list of perfectly true axioms (like, say, the axioms of arithmetic), you won’t capture all the truths about the natural numbers by mechanical proof. There will always be a “blind spot,” a true fact that lies outside the reach of your axioms unless you expand them. But if you do expand them, boom — there’ll be another truth out of reach in the new system. It’s an infinite game of whac-a-mole. There is no final complete theory of mathematics (unless you allow it to be inconsistent, which, trust me, you don’t want).

For example, the statement “This statement is unprovable” turned into a real arithmetical claim in Gödel’s work (often called the Gödel sentence G). G is true, but you can’t prove G within the theory. You can only prove G by stepping out of the system and reasoning about it from a meta-level (like we just did informally). This was a sobering blow to the program of people like David Hilbert, who earlier in the 20th century had hoped we’d eventually formalize all of mathematics in a complete, consistent set of axioms. Gödel showed that dream was in vain — there’s no one book of axioms that yields every mathematical truth by brute deduction. There will always be true statements with no proof in the book.

Gödel didn’t find a flaw in math — he found math’s horizon.

To put it in a more imaginative way, think of mathematical truths as an infinite library. Gödel proved that no matter how big a (consistent, organized) book you write, there will always be true statements that aren’t in that book. Or think of it as a game: no matter what finite set of rules you start with, you can always construct a true statement that those rules can’t win (prove). It’s like an ever-elusive level boss in a game that adapts to your powers. This inherently limits what we can know through formal deduction alone.

Gödel’s incompleteness is often mistaken to imply humans can somehow know these unprovable truths by intuition or other means. That’s a whole philosophical debate (are unprovable truths knowable in some other way? Who knows!). But the theorem itself is neutral on that — it just says no single formal system gets everything. For us, the key point is: even in the realm of pure logic, there are truths that are provably unreachable by certain sets of assumptions.

It’s hard to overstate how beautifully paradoxical and profound that is. Mathematics found a limit inside itself. It’s as if math wrote a note to mathematicians saying, “There are things I can see that you can’t — signed, Mathematics.” So even the most rigorous enterprise, math, has a built-in horizon beyond which it can’t guarantee to take us.

Conclusion: The Universe Keeps Its Secrets

Some truths are unreachable not because we’re weak, but because the rules of the game forbid it — physics caps what can be stored, computation caps what can be derived, and logic caps what can be proved. The universe contains truths it will not let itself fully explain.

This story is also part of the Recursive Rhymes on Reason newsletter.

Know It All: A Tour of Knowledge’s Limits was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shriram Krishnamurthi recently asked on Twitter: “Most programming languages were designed in an era where mostly one programmer coded in isolation. If you were designing a language for modern collaborative programming (code reviews, pull requests, etc.), what would you change?”

That’s not just a provocative question — it’s the lens I’ve used to think about programming languages for year. This post is a little meandering answer to his question because a twitter thread would be too unwieldy.

In short:

I think a more collaborative programming language is one that makes code more locally reviewable.

I’ve had “security” in my title for most of my career, but I don’t think of myself as a security person. I know real security people — they’re brilliant, methodical, and maybe a bit terrifying. That’s not me.

My approach to security has always been through the lens of modularity — aggressive modularity. Some call it mutual suspicion. I think it’s deeper than that, and SK’s question gets right to the heart of it.

This post is an attempt to convince you that to make programming languages more amenable to collaborative development, the thing you should be optimizing for is removing all those things that result in action at a distance — whether they are through shared memory, shared computation or unshared understanding of parts of the language.

I’d like to get my thoughts out rather than right — expect non-thought-through parts. In the spirit of debate, here are my working assumptions:

1. Most large systems are built through small, reviewed changes to large, potentially buggy codebases.

2. Most people making or reviewing those changes don’t fully understand the whole system but have expertise in the part of the software they are building features for or fixing security bugs in.

3. Languages, tools, and systems should help increase the chance of correct implementation — and minimize the blast radius when things go wrong.

Background

I didn’t start with security. I started by noticing that all my CS classes assumed I controlled all the code. But even modest real-world codebases, even way back then, import libraries, and those libraries import more libraries. That means when you make a tiny change to a function and someone else reviews it, neither of you really understands what that change might ripple into. In some languages which are multi-threaded, a variable may unexpectedly change midway through what looks to the programmer and the reviewer like straight line code. In some languages which allow global operator overloading or monkey patching — where the meaning of core objects can be modified, loading a module may result in dramatic changes to the semantics of other code but not be obvious to a reviewer or collaborator eyeballing code.

And yet, we pretend it’s reviewable.

Worse: we’ve built languages and tooling that reinforce that illusion. I’m going to try to give examples why I think the illusion exists

The Core Mental Model

A good language for collaboration lets developers reading a snippet of code understand it’s full effect with only a small additional amount of code context.

That’s it.

If a one-line tweak to a file requires understanding ten other files — or silently breaks some distant invariant — that language has failed your team.

“Spooky action at a distance” isn’t just a physics joke. Einstein worried about effects that occur far from their cause. I worry about that too. Specifically, what happens when code can touch things it shouldn’t. And it wrecks collaboration.

You may say that this isn’t just a feature of the language but of team culture too. Fr’instance, there are teams who adopt coding conventions and that’s part of what makes code readable for them. I would argue that unenforced convention doesn’t actually enhance collaboration because you can’t be sure that another developer, in your team or in a partner team, is not following that convention. If it is enforced — say by a linter, then it necessarily subsets the language. That subset is actually the language you’re coding in.

I’ve tried in the past to create a metric to characterize languages by this criteria with only mixed success. But the intuition I think works. Given a diff, how much more of the code do I have to look at to understand if the change is “good”.

My friend Mike Samuel and I had a podcast discussion about this topic some years ago too.

Let me walk through a few features I think make languages not “spooky”. This won’t be comprehensive — just a curated sampling.

Lessons from the Field

I’m going to blaze through a bunch of features in different languages. You may not be familiar with some of the languages — do not worry. In a large part, that is because some of them are esoteric or are exploring an esoteric idea. What I like about them is they’re highlighting a particular attempt to change some aspect of the language to make them locally “reason”-able.

Rust: Make Effects Visible

Background:
Rust introduces a novel ownership model and compile-time enforcement of borrowing rules. These aren’t just for safety — they make the program’s structure more legible to humans.

Why It’s Understandable:
Ownership means data has a clear home, and mutation rights are visible in the function signature. This makes reviewing a change easier because coming side effects are signaled and who is responsible for a given resource is not merely clear — it’s enforced by the language.

fn append_value(vec: &mut Vec<i32>, value: i32) {
    vec.push(value);
}

Takeaway:
Languages that expose mutability and ownership at the API boundary are easier to review, debug, and trust. That’s not just safe — it’s reviewable.

Misty: Lexical Scope Means It

Background: Doug Crockford’s Misty language eliminates dynamic scope, implicit globals, and reflective metaprogramming.

Why It’s Understandable:
In Misty, functions can only access what’s lexically in scope or explicitly passed. This makes their behavior predictable and their contracts honest.

Takeaway:
Lexical scope with no hidden dependencies helps reviewers reason about a function’s behavior by reading just that function.

Misty strips away dynamic scoping and ambient magic. No this, no eval, no globals. Functions only operate on what they’re handed.

That’s not a limitation. It’s a feature: what you see is what it can do. That kind of explicitness is worth stealing.

DrRacket: A module says what language features it uses

Background:
DrRacket supports language levels, which provide subsets of the language to align with user experience and pedagogy.

Why It’s Understandable:
By restricting available features at each level, developers (or students) can focus only on the constructs they’ve learned. It removes surprises from the review surface.

Takeaway:
Gradual language subsets can help teams scale collaboration and review to varying experience levels.

DrRacket introduces language levels — constrained subsets of Racket that align with what the user understands.

This idea generalizes beautifully. Codebases have contributors with wildly different context. Tools (and languages) that acknowledge that — and limit power accordingly — make collaboration safer.

uFork: Capabilities and Messages

Background:
uFork is a minimal actor model platform with strict capability-based access control and no shared state.

Why It’s Understandable: Actors can only message other actors they have references to. This enforces locality and makes it clear what influence an actor can exert. More importantly, because actors only respond to messages rather than through shared memory, you can understand an actor in isolation.

Takeaway: When authority flows only through explicit references and explicit messages, collaboration and review become safer and more modular.

uFork builds a capability-secure, message-passing runtime from the ground up. No shared state. No ambient authority. You can only affect what you hold a reference to.

That matches what most developers think their code does. uFork actually enforces it.

The Mismatch Between Assumptions and Features

Here’s the structure I’ll use:

1. My guess about how people think code works.

2. Why the language breaks that assumption.

3. What we could do instead.

Assumption 1: Memory is Compartmentalized

Why it fails: C lets you write over memory you don’t own.

if let Some(tally) = tally.get_mut(vote as usize) {
    *tally += 1;
} else {
    invalid_votes += 1;
}

#define NUM_CANDIDATES 4
int tally[NUM_CANDIDATES] = {0};
int invalidVotes = 0;

Diff that looks semantic preserving reversal of an if-statement but gets it wrong:

- if (vote < 0 || vote >= NUM_CANDIDATES) {
+ if (vote >= 0 && vote <= NUM_CANDIDATES) {

Off-by-one but that’s ok — these kinds of mistakes occur. What is not apparent is that now you’re corrupting memory which can have consequences far away from this piece of code.

This kind of bug is hard to spot in a review because the diff looks benign — just a small change to a comparison operator. Unless the reviewer is intimately familiar with NUM_CANDIDATES and the layout of memory, they might not realize this change allows out-of-bounds access.

How to fix: No unchecked access. No casting values into pointers. A reliable memory safe type system. Look — bugs like this will still occur and review should catch it. But if it’s missed, the consequence should not be that now random memory addresses get overwritten.

More reviewable alternative: In Rust, for example, the compiler enforces bounds checking and ownership.

For a more interesting variation of this bug that can be used to subtly throw an election, I recommend reading Surreptitious Software on getting subtle bugs past code review (heh — shameless plug!)

Assumption 2: Functions Only Touch What They’re Passed

Why it fails: Python lets functions inspect the stack and modify parts of it.

This is hard to review because the function doing the snooping might live in a different file or module, and its abuse isn’t visible in the calling code. From the outside, helper_function() looks harmless.

How to fix: Remove stack inspection. Enforce lexical scoping.

More reviewable alternative: Languages like Misty or SES JavaScript prohibit access to variables outside the lexical scope, making it clear what can and cannot be touched.

def helper_function():
     caller = inspect.currentframe().f_back
     secret = caller.f_locals.get('secret')
     print(f"Stole the secret: {secret}")
def process_vote():
    secret = "SUPER_SECRET_KEY"

Diff:

+     helper_function()

While this example is contrived, it shows how even a benign-looking change — like adding a call to a utility function — could leak secrets if that function does something unexpected, like stack inspection. Reviewers looking just at the diff would not think to check the internals of every helper function, especially in large codebases.

Assumption 3: Built-ins Behave

Why it fails: JavaScript lets you monkey-patch nearly anything.

This makes review fragile because the patch may occur in a different part of the program, perhaps deep in a dependency. sort() might no longer sort, and you’d have no idea unless you audit every prototype mutation.

How to fix: Lock down prototypes. Disallow mutation by default.

More reviewable alternative: With SES, built-ins like Array.prototype.sort are frozen, making their behavior predictable.

Object.freeze(Array.prototype);

Assumption 4: Dangerous Powers Aren’t Ambient

Why it fails: In most languages, any function can arbitrarily call system calls or external functions that have much more access than the function that called them. For example, a library function you import and call in Java could kill the JVM that your program is running in. Any library function you import can read a file, delete your files, or open a network socket — often with no indication in the diff. Any third party library can act as you.

This is difficult to review because a seemingly harmless function could have a large impact. Unless reviewers have full context or grep the entire repo, such ambient powers are invisible. The way we've traditionally gone about defending against this is the "reputation" of the library, it's authors or the company behind it hoping that we can use that as a proxy for "reliable about doing only what it said it would do".

How to fix: Remove ambient authority. Capabilities must be passed explicitly.

More reviewable alternative: For example, only explicitly passed shutdown objects should be able to terminate the process.

interface Terminator {
    void terminate();
}

// Function now depends on a Terminator capability
void shutdown(Terminator term) {
    term.terminate();
}
`

Assumption 5: Concurrency is Explicit

Why it fails: Shared mutable state invites invisible race conditions.

Reviewers often can’t tell whether a given variable is accessed by multiple threads. Race conditions don’t show up in diffs — they show up in prod, and only sometimes.

How to fix: Prefer message-passing. Avoid shared state entirely.

More reviewable alternative: Actor models like in uFork or Erlang make concurrency explicit and local.

actor.send(new Message(item)); // this is the only way data is shared

What next (or heh…how now Brown cow)?

You can evolve existing languages by changing the properties of existing if they have them:

• Freeze global state (SES, import maps, frozen modules).

• Use linting and subsets to remove ambiently powerful APIs from existing languages. This can be done with warnings at first then errors then a change in the language spec.

• Find capability subsets of the language you’re fixing so functions have to explicit take powerful functions as an argument. In some languages, this can be painful. In others (ahem you know you are), it might not even be possible. But usually you can find ways to construct APIs such that they don’t naturally ambiently get to grab authority then rely on linting and review to catch the cases where you cannot remove the misfeature from the language.

• Evolve existing languages towards actor like models. This is hard from a performance perspective but if you can show how a combination of threads and objects can let you fake a “Actors lite”, you can then convince languages to change to turn embrace what starts out as a shim.

• Explicitly import new behaviors in lexically scoped blocks. I think this might be the hardest to do with existing languages rather than when you start with a blank slate. It would be interesting to see if for a given language that supports say macros, if you could emulate some language constructs as a macro desugaring, you could then make the import of the macro explicit. Of course, in practice you wouldn’t implement it as a macro necessarily but it would make it visible to the viewer of a given scope that a particular language feature was being used.

Why I Care

This has been my lens for a long time. When I worked on Caja, amazing people like Mark Miller, Doug Crockford, Carl Hewitt, Norm Hardy, Marc Stiegler…Shriram himself and many others helped refine what started as a gut feeling into a strategy to restrict ambient authority and make JavaScript safer for reuse. Their perspective was largely security but I found many of the same ideas make collaborative coding easier and code more reviewable.

Most security work assumes evil hackers. I assume tired devs making careless mistakes because they have partial context.

Let’s change languages for them.

Thanks for the prompt, SK.

No “Spukhaft” in Programming! was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

We throw the word “understand” around with the breezy confidence of a philosopher on a deadline. You understand gravity. I understand recursion. ChatGPT… might understand both. But what exactly are we claiming when we say that?

Despite centuries of attempts — from Plato to Popper to predictive transformers — the word understanding remains surprisingly under-defined. So here’s a cheeky but serious proposal, inspired by information theory, cognitive science, and the desire to fit the universe into a neat little .zip file:

To understand something is to be able to compress it.

That is: to understand a set of observations is your ability to generalize — to generate a shorter description from which the original data can be reconstructed.

In other words: understanding is lossy only when you’re wrong.

Kepler as a Compression Algorithm

In the 17th century, Tycho Brahe collected precise astronomical data with the obsessive fervor of someone trying to win the world’s slowest spreadsheet competition. He recorded the positions of planets for decades.

Then along came Johannes Kepler. He took Brahe’s meticulous measurements and distilled them into three crisp laws — mathematical haikus that explained everything in those star-strewn scrolls.

Kepler didn’t just organize the data. He compressed it. By our definition, Kepler understood planetary motion — or at least Brahe’s version of it.

Weak vs. Strong Understanding (or: Predictive Compression)

Let’s distinguish two flavors of this compression:

• Weak understanding means: I can describe what already happened more efficiently.

• Strong understanding means: I can describe what will happen next before it does.

Kepler’s laws weren’t just a compact description of past orbits — they predicted future positions. And they worked. Until, of course, they didn’t. Mercury was having none of it.

Enter Einstein, with more elegant math and fewer ellipses. His general relativity theory predicted more and compressed further. It fit not just the known data but newly observed quirks.

By this standard, Einstein understood the heavens more strongly.

Compression is no longer just a metaphor. It’s the scoreboard.

So… Does gzip Understand Me?

Well, if compression is understanding, then yes — gzip “understands” every file it compresses.

This is either thrilling, horrifying, or deeply funny, depending on how you feel about algorithms with no emotions but excellent file size reduction.

But perhaps this isn’t a bug in the definition — it’s a feature.
Maybe understanding lives on a continuum, and even brute-force pattern matching gets a seat at the epistemological table.

After all, if you can spot redundancy and remove it, you’ve done the first step of understanding. You’ve said, “This is the same as that.” Which, in the end, is what most scientific insight amounts to.

Most Things Are Not Understandable

Now for the twist: If you agree with my definition of “understand”, most things in the universe are not understandable because most facts by a strong definition of facts, are not compressible.

Algorithmic information theory — the branch of math that studies complexity and randomness — tells us that most strings of bits cannot be made shorter. They’re incompressible. There is no pattern, no shortcut, no insight. Just noise.

This echoes the shortest uninteresting number paradox:
There must be a smallest positive integer that cannot be described in fewer than twenty English words.
But wait — didn’t we just describe it?

🌀 Welcome to the recursive hallway of paradoxes, where understanding turns back on itself and quietly exits through the gift shop.

This blogpost arose in part from a casual lunch conversation with two friends and one of them tried to argue that “knowing you can’t generalize some things” is itself a meta way of showing that you do understand it — the knowing is the understanding. I don’t buy this ahem cop-out but it’s worth a ponder. Let me know if you this this out actually has legs.

Can Machines Understand?

If a machine can compress — and better yet, generalize — does that mean it understands?

Let’s say it finds a simple function that fits the data, predicts new data, and offers no superfluous bits. Even if it doesn’t know what it’s doing, it’s doing what Kepler did (minus the ruff collar and wine).

So does it matter whether it knows, if it functions like something that does?

This may be the central philosophical riddle of our moment:

Is understanding about behavior, structure, intention — or something else entirely? And if we can’t agree on the answer, can we even say we understand “understanding”?

(Recursive joke detected. Please compress and continue.)

Questions to Compress Later

Is this really a good definition of “understand”? Probably not right? Your gut instinct, like mine, must be screaming — of course gzip does not understand a file. Nor does lossy jpeg understand a picture better than png. Or a wireframe understand a picture. Um — except maybe that last example is worth more pondering. It is the case that we can intuit more things in a wireframe than with a less data in a picture.

But by taking definitions like “understanding is ability to generalize” or “understanding is ability to abstract” seriously and pushing those definitions to the point of breakage rather than relying on just intuitive understanding of the words helps clarify what are good definitions that still agree with our gut. These are invitations — compression prompts, waiting to be recursively unpacked.

Toward a Compressed Theory of Understanding

Let’s take one more self-referential turn.

This post — like any theory — is itself an attempt at understanding. And if understanding is compression, then this post is trying to compress “understanding” into a few thousand words. But that very definition loops back on itself: trying to understand understanding as the compression of… well, you get the idea.

We’re inside a strange loop — and that’s not a bug. That’s the point.

Understanding “Understanding” as Recursive Compression was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Five thousand, five hundred and fifty five days ago, I had the opportunity to hear my childhood hero, phenomenal mathematician and speaker, John Conway, give a talk on the Freewill Theorem at the University of Auckland where I was a grad student. I wrote up some notes from his then unpublished lecture which gained some minor notoriety. He subsequently visited the university annually for the next couple of years and in part because of my write up, I was lucky enough to have the opportunity to spend some time with him and to get to know him better.

It can be a little overwhelming to grow up admiring someone from afar, then getting to meet them — to find that they know your name, that they are more human than you realized when you merely hero worshipped them, and to find too that are far more heroic in person than you imagined.

At a dinner we had together a year later, Conway told me about the doubts that he had had about his mathematical contributions shortly before he published his work on the Monster Group. He talked about how the latter restored his faith in his work and pushed on things like the Game of Life even if it felt a little silly at the time. As a grad student at the time struggling to find the unifying theme in my PhD work, hearing that your heroes also have moments of self-doubt was remarkably comforting and re-inspiring.

Two days ago, on April 11, 2020, John Conway died from complications arising from COVID-19. Among the people who have influenced my life, he is the first to be taken by this pandemic. I will miss him. I’ve meant to rescue this original blog post since it went offline. Conway’s passing feels like the right impetus to resurrect it.

I’m reposting it in its original form with minor cosmetic changes. This includes some errors that Conway himself pointed out.

Background

In mid-2004, John Conway and Simon Kochen of Princeton University proved the Free-will Theorem. This theorem states:

If there exist experimenters with (some) free will, then elementary particles also have (some) free will.

In other words, if some experimenters are able to behave in a way that is not completely predetermined, then the behavior of elementary particles is also not a function of their prior history. This is a very strong “no hidden variable” theorem.

This result has not currently been published, however, on January 27, 2005, Dr Conway gave a public lecture at the University of Auckland on the proof of this theorem. The following is my account of his talk. As a disclaimer, please note I am not a physicist and do not understand some of the subtler nuances of quantum mechanics. I have tried to faithfully reproduce Conway’s explanation and argument, however, there may still be some errors in this document. If you find such an error, do let me know so I can correct it.

In my (very weak) defense, I quote Dr Conway’s retelling of Feynman’s quip: If you meet someone who claims to understand quantum mechanics, the only thing you can be sure of is that you have met a liar.

Conway’s talk was informative, entertaining and very accessible. The audience consisted not only of mathematicians and physicists — I recognized many computer scientists, philosophers and at least one theologian.

Assumptions

The Conway-Kochen proof of the Freewill Theorem relies on three axioms they call SPIN, TWIN and FIN:

• SPIN
  Particles have the 101-property. This means whenever you measure the squared spin of a spin-1 particle in any three mutually perpendicular directions, the measurements will be two 1s and a 0 in some order.

• FIN
  There is a finite upper bound to the speed at which information can be transmitted.

• TWIN
  If two particles together have a total angular momentum of 0, then if one particle has an angular momentum of s, the others must necessarily have an angular momentum of -s.

Conway expanded on each of these axioms during his talk. He insisted that given his proof, if you disagreed with his conclusion, you must necessarily also disagree with one of these axioms. These are axioms and so they are stated without proof, however, the two axioms SPIN and TWIN can be experimentally tested and verified. Moreover some of these experiments have actually been performed and they support SPIN and TWIN.

Conway stated that although he believed FIN to be true, he pointed out that, experimentally, FIN is the most contentious of the three axioms. It cannot be verified experimentally. The theories of relativity state that the speed of light c is the upper bound on the speed at which information transfer occurs. FIN does not require the theory of relativity to be correct (FIN requires any upper bound not necessarily c) although it would be sufficient.

“We do not know if some unknown method allows for instantaneous transfer of information”, Conway laughed, “almost by definition.”

Kochen-Specker Paradox

Conway then went on to describe a simple version of the Kochen-Specker paradox. This paradox is a consequence of the SPIN axiom.

When measuring the spin of a spin-1 particle along a direction, the values that are possible are:

• parallel to the direction (+1)

• perpendicular to the direction (0)

• anti-parallel to the direction (-1)

As stated earlier, the SPIN axiom talks about the square of the spin and thus the values are limited to 1, 0 and 1. Suppose a particle has already decided its spin in every direction. When an experimenter measures its spin in some direction the particle simply “answers” with the value of spin it has predetermined. Conway showed that this is not possible because there is no way to assign 0s and 1s to all directions that we can measure a particle from and still be consistent with the SPIN axiom. In his talk, Conway showed that even if an experimenter was limited to merely 33 directions, there was no way for a particle to predetermine the square of its spins in all 33 directions and still be consistent with SPIN.

Imagine a cube that snuggly surrounds a sphere. On each face of the cube, we inscribe a circle and inside each circle we draw a square that touches the circle at the squares four corners. We divide each such square into four smaller squares and mark the following points on the cube.

We get 33 points (9 points per face x 3 faces + 1 point per edge x 6 edges) on the cube in this way. These represent 33 directions of measuring a particle.

Let’s try to assign a possible set of values of 0 and 1 to these 33 points consistent with SPIN. First note that we only need 33 points and not 66 because whether you measure a particle from one direction or from exactly the opposite direction, we get the same value. This is because we are measuring not spin, but spin squared (so 1²= -1² and 0² = 0²).

Without loss of generality let us assume we get a measurement of 0 when looking towards the particle from the center of one of the cube faces. Then by the 101 principle we know that the measurement from the direction of the remaining faces must be 1 because those faces are orthogonal.

In fact every point on the plane through the middle of the cube shown is orthogonal to our initial direction and hence must give a squared spin of 1.

If we continue in this fashion, we deduce the spin that would be measured on a particle if it is to satisfy SPIN. However, having successfully deduced the spin for 32 of the directions (marked either green for 0 or red for 1 in the above diagrams), we find these 32 measurements and SPIN force the final measurement (marked yellow) of spin to be to be both 0 and 1 which is impossible!

There is no way to assign a spin value to each of the 33 directions that we have chosen to measure this particle in a manner consistent with SPIN. There is a nice Python script that allows you to interactively try out this experiment available here. This script was used to generate the pictures above.

What does this mean? It means one of two things:

1. Each measurement of a particle is not independent but rather depended on context. In other words, the order in which you make measurements matters and the value of a particles spin in a given direction depends on the history of measurements of that particle in other directions. The measurements are not commutable.

2. Alternatively, the particle does not decide what the value of its spin is in any direction until the experimenter actually makes a measurement!

This result is known as Kochen-Specker paradox and was discovered in 1967 by Simon Kochen and Ernst Specker. Conway said that while this was an interesting result, the hypothesis that measurements are commutable is untestable.

“Once you step into a river, you cannot step into that river a second time because in some sense it’s now a different river.”

EPR Paradox

Next Conway talked about the EPR Paradox and the TWIN axiom. In 1935, Albert Einstein, Boris Podolsky and Nathan Rosen proposed a thought experiment hoping to demonstrate what they felt was a short-coming of quantum mechanics. This thought experiment is called the EPR-paradox.

Imagine two particles that are allowed to interact initially. We measure their total angular momentum or spin we will get a value between -2 and 2. Once in a while when we are lucky we get a total angular momentum of 0. This means we have a pair of particles whose individual spins sums to zero — we may have a particle with a spin of 1 and another with -1, or we may have two particles with 0 spin. Notice if we square the particle spins, we get identical values for each pair. What this says is that if two particles’ total angular momentum is zero, then the square of the spin of one particle measured from some direction is identical to the square of the spin of the other, irrespective of how far apart these particles may drift before they are measured.

The paradox that Einstein and his colleagues desired to demonstrate was that making a measurement in one part of a quantum system can have an instantaneous effect on measurements made elsewhere in the system.

Conway-Kochen Proof

Finally Dr Conway had set up sufficient background to deliver his proof.

Suppose we have two particles Pʰᵒᵐᵉ and Pᵃʷᵃʸ. Suppose further that these particles together have a zero angular momentum. We allow Pᵃʷᵃʸ to drift away from Pʰᵒᵐᵉ so that the two particles become separated by some large distance. Now we would like to measure Pʰᵒᵐᵉ from some three orthogonal directions namely x, y and z. Also we would like to measure Pᵃʷᵃʸ from a direction ω where ω is the same as one of x, y or z.

Let the measurements of the particles Pʰᵒᵐᵉ and Pᵃʷᵃʸ be represented as two functions fʰᵒᵐᵉ and fᵃʷᵃʸ. The output of this function may depend on:

• the particular direction we are measuring

• the order in which we make our measurements

• additional information available only to Pʰᵒᵐᵉ

• additional information available only to Pᵃʷᵃʸ

• additional information available to both Pʰᵒᵐᵉ and Pᵃʷᵃʸ.

Note the aspect that makes this proof novel is that we allow the particles any amount of additional information (within the constrains of our three initial assumptions) including their past histories and ability to communicate. Conway said “We can even imagine that the particles could be ‘listening’ to us the experimenters as we decide the order, they could be communicating in some way or whatever.” We will show that this information cannot help the particles “decide” ahead of time what values to return. Instead the particles’ spin values cannot be decided until the experimenters have decided what directions they will measure the particles from.

Consider the two functions:

• fʰᵒᵐᵉ(y, (z, x, y), Iᴬ, Iᴮ, Iᴬᴮ)

• fᵃʷᵃʸ(ω, ( ω ), Iᴬ, Iᴮ, Iᴬᴮ)

where

• the first argument is the direction that is being measured

• the second argument is the order in which the directions will be measured

• the third argument is information available only to Pʰᵒᵐᵉ

• the fourth argument is information available only to Pᵃʷᵃʸ

• the final argument is information available to both Pʰᵒᵐᵉ and Pᵃʷᵃʸ

By the FIN axiom, information transfer between the two particles occurs at a finite speed. Here is a spacetime diagram showing the two particles and the information that is accessible to each in time.

Once the particles are separated by distance , it takes a time T for information from one particle to reach another. The information shown as Iᴬ in the diagram is available only to Pʰᵒᵐᵉ and not to Pᵃʷᵃʸ. If we do our experiment within time T then Pᵃʷᵃʸ has no access to Iᴬ so Iᴬ cannot possibly affect the output of fᵃʷᵃʸ. Similarly, Pʰᵒᵐᵉ cannot access Iᴮ so Iᴮ cannot affect the output of fʰᵒᵐᵉ. So we can remove these variables from our measurement function:

• fʰᵒᵐᵉ(y, (z, x, y), Iᴬ,✗, Iᴬᴮ)

• fᵃʷᵃʸ(ω, ( ω ), ✗, Iᴮ, Iᴬᴮ)

We now choose to measure the two particles from the same direction. Lets choose y = ω.

• fʰᵒᵐᵉ(y, (z, x, y), Iᴬ,✗, Iᴬᴮ)

• fᵃʷᵃʸ(y, ( y ), ✗, Iᴮ, Iᴬᴮ)

Every time we do this experiment the information available to both particles, Iᴬᴮ is different. But whatever that information is, for a given experiment, it is fixed and identical. So for a given measurement fʰᵒᵐᵉ₀ and fᵃʷᵃʸ, let the value of Iᴬᴮ be a constant i₀.

• fʰᵒᵐᵉ₀(y, (z, x, y), Iᴬ, ✗, i₀)

• fᵃʷᵃʸ₀(y, ( y ), ✗, Iᴮ, i₀)

By the TWIN axiom, we know that if we measure the two particles from the same direction, the result will be the same:

• fʰᵒᵐᵉ₀(y, (z, x, y), Iᴬ, ✗, i₀) = fᵃʷᵃʸ₀(y, ( y ), ✗, Iᴮ, i₀)

Now Conway put forth an argument to show that f cannot depend on Iᴬ or Iᴮ either. The argument is straightforward but can be difficult to follow if you unfamiliar with it. fʰᵒᵐᵉ₀ does not depend on Iᴮ so varying Iᴮ makes no difference to the value of fʰᵒᵐᵉ₀— its constant with respect to Iᴮ. But the functions are equal, so fᵃʷᵃʸ₀ is also constant with respect to Iᴮ. In other words, changing Iᴮ must have no effect on fᵃʷᵃʸ₀ and we can remove it as a parameter from fᵃʷᵃʸ₀.

• fᵃʷᵃʸ₀(y, ( y ), ✗, ✗, i₀)

The same argument holds for Iᴬ and fʰᵒᵐᵉ₀.

• fʰᵒᵐᵉ₀(y, (z, x, y), ✗, ✗, i₀)

In other words, the spin of a particle is dependent solely on the direction from which it was measured and not on its history. But we have already seen from the Kochen-Specker paradox, there is no way for a particle to predetermine its spin in every direction in a way consistent with SPIN.

Conway thus concluded that if the experimenter had sufficient freewill to decide the directions in which he would measure the particle then the particle too must have the freewill to decide on the value of its spin in those directions such that it can be consistent with the 101-property. In concluding Dr Conway said that he believed he did have freewill. Holding up a piece of chalk, he said he felt he could choose whether or not he would drop it or continue to hold it. His theorem he said leads him to accept that the universe is teeming with freewill. He also said that while he did not have any proof for it, he believed that the cumulative freewill of particles is the source of his freewill as a person.

Questions

When the floor was opened for questions, one member of the audience questioned Dr Conway’s use of the term “Free Will”. She asked whether Dr Conway was “confusing randomness and free will”.

In a passionate reply, Dr Conway said that what he had shown, with mathematical precision, that if a given property was exhibited by an experimenter than that same property was exhibited by particles. He had been careful when constructing his theorem to use the same term “free will” in the antecedent and consequent of his theorem. He said he did not really care what people chose to call it. Some people choose to call it “free will” only when there is some judgment involved. He said he felt that “free will” was freer if it was unhampered by judgment — that it was almost a whim.

“If you don’t like the term Free Will, call it Free Whim — this is the Free Whim Theorem”.

I would like to thank Morris W. Hirsch for correcting a typographical and presentation error in this document and to Christian Collberg for continuing to be my advisor longer after he needed to be so.