An Optimal Programming Language for LLMs

"You hear that Mr. Anderson? That is the sound of inevitability. It is the sound of your token-spend."

– Agent Smith, The Matrix (approx.)

How inevitable that a trade known for celebrating efficiency and optimization would eventually shift from spending as much as possible on tokens to tightening that token budget.

That’s not to say that there’s no place for experimentation and learning. Many developers were driven as much by curiosity about LLMs as they were by a mandate to consume them. But experimentation must at some point turn away from novelty that produces lines of code to more meaningful and measurable outcomes.

And what better measure than the efficiency of token spend. The instigating institutions, self-interested model providers, extolled optimal coding in terms of vibes and volume. And while that blossomed into substantial spending, it left behind a cruft of software that ignored the craft of software.

So what would be some good programming language properties for LLM budgets? What languages have a brevity of syntax and semantics such that they would translate to tinier token creation?

Very Verbose vs. Sufficiently Succinct

TypeScript is an easy example of an expensive language. It adds so much decoration that disappears when transpiled to JavaScript. All those annotations do is help humans understand the context and constraints around the project's data and functions, or give the compiler something to complain about when types don't match. But they’re tedious for LLMs to consume and create. Why bother with so much text that gets thrown away for production? Humans might need those reminders to jog their memory. But LLM coding prompts just need a concise closing clause like, “...and make it secure.”

That’s not to say that JavaScript doesn’t helpfully try to cut corners. Unfortunately, cutting things down like only having 53 bits for integers instead of 64 doesn’t translate to token efficiency. It just occasionally surprises humans. Humans don't look at the world through the lens of floating point numbers. LLMs do.

JavaScript can also be manipulated into minimizing its character set, which we'd hope would translate to tinier tokens. We’ve seen general guidance around this where APIs are encouraged to return sparse markdown instead of HTML in order to avoid spending money on all those angle brackets, tags, and attributes. LLMs don't care about the size or color of a font. They faithfully adhere to the security motto of, "If you see something, say something."¹

Thus, a smaller and shorter input range of characters seems economically favorable. A heading indicated by a leading # ... in markdown is more token efficient than wrapping it within <h1>...</h1>.

JavaScript's object and type model has some quirks that almost help here. For example, rather than use a literal string like alert, you can craft the same string through clever manipulation of objects and arrays like, (![]+[])[1] + (![]+[])[2] + (![]+[])[4] + (!![]+[])[1] +(!![]+[])[0]. This reduces the set of characters to tokenize. Yet sadly, it explodes the amount of tokens to consume. Such is the curse of premature optimization.

Still, punctuation feels like a fruitful path to explore for efficient languages. After all, if we can imbue an ancient telegram token like “STOP” into a period, that’s a good optimization. If we can imbue the semi-colon that signifies the termination of a line of code into a newline character, that’s another. Go removed the semi-colon burden from our humans brains by making the compiler toolchain silently add them in wherever the specs says they should go².

Lisp and its ilk have plenty of punctuation. Their parenthetical policy encourages simplified and condensed source, for example (Parse (:this (kind (:of :thing)))).

(Lisp even has mutable dynamic variables denoted by *earmuffs* and constants between +plus-signs+. That's some powerful punctuation!)

LLMs fly through a cascade of closing characters like that. Lisp's style guide also explains the hierarcy of comments denoted by four, three, or two semi-colons. Again, LLMs just chew through those single characters quickly.

But if we’re going to rely on syntax to shorten our token spend, we can do better.

Probably Effective and Reasonable Language

We can use Perl. Perl must surely be the ideal LLM programming language. It was created for – and excels at – text processing.

Perl, who's pedigree dates back to the late 80s, predicted and practiced the probabilistic nature of LLMs with its early design slogan, “There’s more than one way to do it.”

Seeing three different Perl programmers come up with seven different solutions for the same problem is just the small-scale version of running an LLM more than once with the same prompt.

Like an LLM, Perl is unburdened by expectations of predictability or a dependable nature. For example, Perl’s list context is well suited to the stochastic nature of LLMs. As the perlfunc doc explains for lists, “[operators] do what you want, unless you want consistency.”

That sentiment is like a reformulation of the quote about technology and magic, “Any sufficiently advanced list operator is indistinguishable from its context.”³

One of the best ways to save on tokens is to not spend them in the first place. In the context of writing code, that means not writing code. Once again, Perl excels in this space by providing a native implementation for unimplemented code with the “yada yada” operator, otherwise known as the three-dot ellipsis (...).

Of course, sometimes three dots is just the same as two dots for a range operator. Ambiguity and surprise are what make LLMs so powerful as text creation systems!

Speaking of operators, you’ll never waste lines of code on no-op expressions – Perl doesn’t have them. Except they do if you really need one. Which is useful flexibility and reinforces the slogan’s subtext of, “There’s more than one way to spend tokens.”

Integers in Perl are superior to JavaScript. You can get a full 64-bit value rather than JavaScript’s paltry 53. Want to work with really big numbers? You can famously implement RSA encryption and decryption in three lines of Perl.⁴

Whereas TypeScript wasted text on describing semantic hints like whether a string represents a name or an email or something else that humans have to remember when writing code, Perl eschews those explanations.

In fact, one of the consequences of a slogan that encourages, “...more than one way to do it,” is that reading someone else's Perl code ranges from frustrating to near-impossible. But not for an LLM.

One Token Over the Line of Code

LLMs don’t need to explain their work, they don’t need to produce human-readable code when that code’s reviewers and consumers are merely other LLMs. All those abstractions of types and decorators and comments are just crutches for human brains that can’t handle the precision of floating point numbers.

Humans long ago realized that measuring their success in creating software was poorly correlated to lines of code. There were so-called "code golf" competitions where they used their knowledge of language quirks to implement a function in the fewest characters possible. But that was an exercise driven by intellectual curiosity that had nothing to do with cost-savings.

But what if all that syntax wasn't as important as what the code actually does? What if the semantics of symbols meant compilers could apply better security to data flows, control flows, and memory manipulation? Maybe TypeScript makes collaboration and maintenance easier. Maybe Rust makes heap allocation mistakes harder.

Maybe it was our natual written and spoken language all along that made better software. Perhaps not completely natural, as betrayed by the stilted or formal language of RFCs and similar specs. But it's close.

Even the emphasis of capital letters in words like SHOULD, MAY, and MUST mostly works on humans. But it's that mostly qualifier that leads to security flaws. And it's the ambiguity of language that leads to disparities between designs and implementations. And those disparities impact software quality.

So maybe we need a better language for humans. Maybe something like math, where operators operate predictably and statements can carry proofs that guarantee behavior. Those kind of concrete properties could be a boon to real-world security. No human mistakes, no LLM hallucinations. Surely there's nothing irrational or imaginary to such an approach.

Meanwhile, I'll continue to enjoy typing text by hand, because the only tokens I care about are the ones used to represent creatures on maps in role-playing games.