EsoNatLangs Bring the Complexity of Natural Language into Code - esoteric.codes, an esolang blog

EsoNatLangs Bring the Complexity of Natural Language into Code

The five esolangs discussed in this piece -- Coem, Love Languages, Prāsa, Kip, and Captive -- draw on aspects of natural language usually avoided in code: nuance and ambiguity, complex grammars and morphologies. They stand apart from the better‑known, jokier esolangs like LOLCODE or RockStar, which borrow from natlangs only for their vocabulary, building lexicons of memespeak or power-ballad lyrics, respectively. Since they keep the same grammar as typical imperative languages, there's a stiffness to the way their natural-language-inspired phrases combine and they still feel code-like. These five langs, which we might call esoNatLangs, do not; they foreground linguistic expressiveness over algorithmic execution.

"Esonatlang" is a play on sub-genres of Oulipo ("the workshop of potential literature" which featured constraint-based writing), e.g. Outrapo, the "workshop of potential tragicomedy." These langs multicode with prose: their programs have multiple readings that constrain each other aesthetically, much like Piet does with images or Velato with music. The constraint sets of some are abstract enough to border the steganographic: an English sentence gives little hint that it is also a Love Languages program on first reading. Other esonatlangs leave more visible stylistic traces, like the musical cadence of Prāsa. But all prioritize code as a text for human reading: their computational aspect -- how they perform as code -- shapes how they are written, rather than serving as a primary goal. As per usual in esolang practice, esonatlangs are made by practitioners from many backgrounds: academics and students, artists, and as side projects by working programmers. The final language, Captive, is one of mine. It should be noted that none of these were made in reaction to each other, and the term esonatlang is my own; this is an emerging trend, not a label these esolangers have necessarily adopted themselves.

If there is a common precursor to this style, it may be the first English‑prose‑like esolang, Shakespeare. This twenty-year-old language was explicitly a joke -- one that has long worn out. Yet it took the first step toward linguistic complexity in code and continues to inspire languages that explore the possibilities it hinted at but didn't fully explore (previously covered: in:verse, Cree#, Ashpaper). While nearly all Shakespeare programs sound the same, it's more sophisticated than the esoteric-in-lexicon-only joke langs like LOLCODE. In Shakespeare, values are expressed in lines of dialogue full of nouns and adjectives classified as positive, neutral, or negative. This creates an enormous lexicon. For example, there are 25 negative nouns, including “pig,” “bastard,” and “Microsoft.” The esonatlangs pick up where this leaves off, moving the lexicon from a static list of words, however large, into abstractions like sentence structure, the pattern of individual letters within larger texts, or the rhythm and flow of phrases.

Esonatlangs are of particular interest in this moment of AI-generated code. Agentic coding uses natural language to negate it. Prompts are discarded as they are too ambiguous, too untrustworthy, so they are discarded. What is kept is the fixed, unambiguous code they resolve to. Not only is the texture of the original prompt lost, but also the personal style of hand-typed code that would have been written in their stead: the small choices that let you recognize one coworker's code from another's.

The esonatlangs invert this logic. They embrace ambiguity and personal expression as the point. They center the text of code over algorithmic efficiency. Below are short introductions to each language.

Coem

Katherine Yang built Coem to explore "the experience of writing and the tactile feeling of words on the page or screen." Its REPL-ish interface evaluates expressions immediately. However, there is no separation between code and the responses from the interpreter. They appear immediately to the right of the line of text they belong to, separated with a dagger. The dagger is usually a sign for a footnote; in Coem it marks both output and comments.

Coem does not treat non-Coem texts are error, it simply ignores it. This means that, in effect, the programmer can include lines of text from outside its grammar; they will simply trigger no output. Whether a program is "correct" in Coem is a secondary concern for its programmer-poets. As Yang describes:

[A] Coem text should look like a piece of poetry writing that can be appreciated on its own — then, when placed into the editor and "run", there might be a secondary delight of experiencing writing that can "run" like code... there's no sense of the "right" set of words (see e. e. cummings or Lewis Carroll); the words you write will do something...