About CL
I’m Benjamin Sullivan. I built CL because I hit the wall it’s built for.
I was eighteen, building my first real product. It shipped, it worked, people used it. And most of the code underneath it, I could not read. I could see it was there. I could tell you roughly where a thing lived. But open a file and tell you what it actually did, what would break if I changed it, whether the logic was right — no. I was approving work I couldn’t check.
That’s not unusual anymore. Three quarters of new code at Google is written by AI and approved by an engineer. The job moved from producing code to judging it, and judging requires reading. I was doing the approving half without the reading half, and I knew it.
So I went looking for the thing that teaches reading. There’s almost nothing, and nothing built the way languages are taught. Every course, every bootcamp, every tutorial teaches you to write code and assumes reading comes free with it. It doesn’t. Everyone who can read unfamiliar code acquired that ability by accident — two years on a junior job staring at a codebase they didn’t write, until it crystallised. And those jobs are gone. Entry-level hiring at the biggest tech companies fell by two thirds. The mechanism that taught everyone to read code was removed, and nothing replaced it.
Then I recognised the shape, because I’d already watched it work at home.
My brother reads full Latin books on about eight hundred words — not by drilling grammar, but by reading, with meaning, until it came. He took a 300-level Latin course and scored 97%. The next-best student, drilled on case endings for years, scored 67%, and couldn’t read a page without stopping to decode every clause.
The one who’d learned to read beat the one who’d learned to decode.
My older brother built his French and Polish the same way — thousands of words through comprehension, not study — until he could pick up a book in either and read it, and spend months in Montréal and Kraków without missing a step. Same method every time, and it comes from LingQ, a reading approach built on one idea: you acquire a language by understanding things in it, not by studying it.
Reading is a skill you build by reading.
I could see it because I wasn’t in the field. Everyone inside it was taught that code is mathematics, so the only available strategy is decoding — work out this symbol, then the next one, forever. From outside it looks like what it is: a writing system with a small closed vocabulary, and no dictionary.
So I measured it. Forty-nine real applications, 6.65 million tokens, every symbol counted and ranked. Thirteen symbols get you eighty per cent of production Python. Four get you half. The same eighty per cent of ordinary English takes about two thousand word families. Then I did TypeScript independently. It takes a few more symbols — eighteen for eighty per cent — but the curve has the same shape, which means the shape isn’t a fact about Python.
It’s a fact about code.
13
symbols cover 80% of production Python
6.65M
tokens measured across 49 real applications
488
dictionary entries, a plain-English meaning for each
Read the data →
Then I wrote the dictionary. Four hundred and eighty-eight entries, each a plain-English meaning, not a definition. As far as I could find, nobody had written one before, because nobody thought a programming language was the kind of thing that has one.
There are two studies that appear to say this can’t work. In 2020, teams at MIT and Johns Hopkins scanned programmers and found that understanding code engages the brain’s problem-solving system rather than its language system. Read the methods: the people in the scanners were solving code — working out what a snippet computes, or whether a function gives a certain result. That’s problem-solving, so it lights up the problem-solving system. Latin gets the same treatment — taught as a puzzle to be solved rather than a language to be read, which is exactly why students spend four years decoding and never arrive. Nobody in those scanners was reading the way a fluent reader reads.
The first reader was me. I sat down with the dictionary I’d just built and read a TypeScript function I had never seen — a type definition and a full signature, cold. I made mistakes, and every one was a defect in my own material rather than in the method: a symbol I’d forgotten to gloss, a word that meant two things in different positions. I fixed them. That’s why the dictionary has the rules it has.
This is a new answer to a problem that is only a few years old. Nobody had to solve it before, because the job used to solve it for you.
What CL can’t do: reading finds what’s wrong in code. It can’t tell you the code is the wrong code — that takes knowing what it was for.
“A man can write his entire life story — what good is it if he cannot read.”