When the point is the punchline
Some languages are built to make someone laugh. The joke might be visible in the name, in the commands or in the way programs look, and often the amusement comes before the usefulness. These are among the most recognizable members of the family of esoteric programming languages, and they are a good way to see how much design can happen inside a single idea.
A joke language is not necessarily a lazy one. A well-made joke is precise: it has a setup, a clear rule and a consequence that follows logically. The best ones also work as real languages, in the sense that programs can be written and run.
Common kinds of joke
Humor in this area takes several recurring forms. The categories overlap, and many languages use more than one.
Exaggeration of a familiar complaint. Programmers often grumble about verbose syntax, fussy punctuation or mandatory formality. A language can take such a complaint to an extreme. A rule that is mildly annoying in practice becomes absurd when enforced everywhere.
Literal-minded rules. The language follows an ordinary phrase so literally that the result is silly. For example, a language might treat politeness as a requirement, or accept only programs shaped like a particular object.
Disguise. The program looks like something else, such as a recipe, a poem or a block of repeated words. This is closely related to the idea of prose-like code, and to the family of Brainfuck reskins that swap the original symbols for different words while keeping the same behavior.
Parody. A language imitates another language or a style of programming, exaggerating its most recognizable features.
Absurd constraints. A language forbids something basic, or requires something pointless, and the programmer must cope.
The deadpan reference. The documentation is written in earnest, describing nonsense as if it were serious engineering. The contrast creates the humor.
How the joke shapes the design
A joke is not just a label. Once it is chosen, it constrains many decisions.
Take a hypothetical language whose joke is that every instruction must be a polite request. The designer must decide how to parse the phrases, whether wording variants are allowed and what happens when a request is rude. The joke turns into rules about syntax and error handling. In terms of syntax and semantics, the humor sits in the syntax, while the meaning of each phrase still has to be defined separately. A joke that lives only in the syntax is easy to build. One that also changes the behavior of the program is harder and often funnier.
The same is true of tone. A language that wants to feel absurd needs enough consistency to be believable. If the rules change randomly, the reader cannot tell whether the odd result is a feature or a bug.
Joke or serious experiment
The line between a joke language and a serious experiment is blurry. Some designs begin as a gag and turn out to have interesting properties. A language that appears silly might still be capable of computing anything, which raises the question of Turing completeness. Another might force a style of thinking that is hard to find elsewhere. When this happens, the joke becomes a way into a real idea, and the humor lowers the barrier for readers who would otherwise find the subject intimidating.
The opposite also occurs. A language can be funny for five minutes and have nothing underneath. That is fine too, but such languages seldom stay in anyone’s memory.
Why humor spreads
Jokes travel well. A good one can be explained in a sentence, and the reader can immediately picture a program in that language. That makes joke languages easy to share, quote and remember, and it is one reason they are often among the first examples a newcomer meets. A funny name does a lot of this work, which is discussed further in the article on naming your language.
Humor also builds community. Sharing an in-joke signals that you belong to the group. Readers who enjoy the idea may go on to write a program, an interpreter or their own parody. For the wider picture of how this happens, see the article on esolang culture.
Writing your own
If you want to try designing one, a few habits help.
- Find a single joke and commit to it. Several gags at once usually dilute each other.
- Make the rules exact. Humor does not excuse ambiguity, and a precise rule makes the joke land better.
- Make sure a program can be written. Without at least one working example, the language is only a description.
- Keep the documentation straight-faced. Let the reader discover the absurdity.
- Stop when the joke is done. Adding features after the point has been made often weakens it.
Results are unpredictable. Whether a joke lands depends on the audience, and what one reader finds clever, another may find merely odd.
What the laughter is for
It would be easy to dismiss all this as silliness, but the habit has a use. A language that exaggerates a flaw makes the flaw visible. A parody of verbose syntax reminds readers why concise syntax matters. A language that disguises code as prose raises questions about what readability actually means. The laughter is a way of noticing things about ordinary languages that are usually invisible, and the better jokes leave the reader with a slightly sharper sense of how programming languages are put together.