2505.15327v2

# Let’s Take Esoteric Programming Languages Seriously **Authors**: Jeremy Singer, Steve Draper > 0000-0001-9462-6802 University of Glasgow Glasgow United Kingdom > 0000-0002-9564-9317 University of Glasgow Glasgow United Kingdom by (2025; 2025-04-24; 2025-08-11) ## Abstract Esoteric programming languages are challenging to learn, but their unusual features and constraints may serve to improve programming ability. From languages designed to be intentionally obtuse (e.g. INTERCAL) to others targeting artistic expression (e.g. Piet) or exploring the nature of computation (e.g. Fractan), there is rich variety in the realm of esoteric programming languages. This essay examines the counterintuitive appeal of esoteric languages and seeks to analyse reasons for this popularity. We will explore why people are attracted to esoteric languages in terms of (a) program comprehension and construction, as well as (b) language design and implementation. Our assertion is that esoteric languages can improve general PL awareness, at the same time as enabling the esoteric programmer to impress their peers with obscure knowledge. We will also consider pedagogic principles and the use of AI, in relation to esoteric languages. Emerging from the specific discussion, we identify a general set of ‘good’ reasons for designing new programming languages. It may not be possible for anyone to be exhaustive on this topic, and it is certain we have not achieved that goal here. However we believe our most important contribution is to draw more attention to the varied and often implicit motivations involved in programming language design. programming language design, esolangs, programming humor copyright: cc doi: 10.1145/3759429.3762632 journalyear: 2025 isbn: 979-8-4007-2151-9/25/10 conference: Proceedings of the 2025 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software; October 12–18, 2025; Singapore, Singapore booktitle: Proceedings of the 2025 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward! ’25), October 12–18, 2025, Singapore, Singapore ccs: Software and its engineering Language types ccs: Social and professional topics Cultural characteristics ## 1. Introduction Despite their name, esoteric programming languages are surprisingly popular in the general Computer Science community. This essay is based on a presentation we have given several times to audiences of academic Computer Scientists interested in programming language design; on each occasion we have encountered keen advocates of esoteric languages like Whitespace and Brainf***. However we have also detected a sense of shame—esoteric language usage is an unexpectedly common ‘guilty secret’. In this work, we seek to analyse potential reasons for these attitudes to esoteric languages. We will argue that Computer Scientists need to take esoteric languages seriously. Let’s start with some definitions: An esoteric programming language (hereafter contracted to esolang, following general convention) is ‘a programming language designed to experiment with weird ideas, to be hard to program in, or as a joke, rather than for practical use’. https://esolangs.org/wiki/Esoteric_programming_language Temkin (Temkin, 2017) characterizes an esoteric programming language as one that is ‘intentionally ununsable, uncomputable or conceptual’. Another definition https://esoteric.codes/blog/esolangs-as-an-experiential-practice is that ‘esolangs are a class of languages made for reasons other than practical use’. More generally, the adjective esoteric relates to philosophical doctrines and modes of speech. It refers to concepts or materials that are appreciated only by an ‘inner circle’ of advanced persons, known as initiates. And, if a definition were needed, a programming language is a systematized notation for precise expression of intended computational behaviour. The ACM encyclopedia definition of ‘programming languages’ (Sammet and Hemmendinger, 2003) describes them as: ‘both tools for directing the operation of a computer and tools for organizing and expressing solutions to problems’. The claim of this essay is that esoteric languages might be inherently useful in some significant ways, and so they deserve to be studied in a serious manner. The first question we seek to address is: What is the appeal of esolangs, in general? Our discussion will cover the following four high-level reasons for their popularity: 1. A sense of fun or playfulness 1. Recalling a lost ‘golden age’ of coding 1. Sense of cultic initiation 1. Artistic value The second question we will address is: What is the appeal of designing esolangs, in particular? We will explore the reasons of parody and comedy, before moving on to considering the skills of working within very tight self-imposed constraints, and the attraction of creating a programming language ‘of one’s own’, as Virginia Woolf might have said. Taking inspiration from Wing’s conceptual framework of Computational Thinking (Wing, 2006), we will ask: what do programmers actually do? We will explore how this characteristic behaviour is manifested in the medium of esolangs. Whereas Wing’s claim is that practitioners in other disciplines can benefit from a grasp of computing principles, our study of esoteric languages leads us to believe that computer programmers can benefit from a wider appreciation of other disciplines. This is Gordon’s argument in his Onward! essay from last year (Gordon, 2024) which takes the complementary stance to Wing, encouraging computer programmers to appreciate natural language and linguistics. In considering pedagogic principles, we will ask Why is it beneficial to expose learners to esoteric languages? We will explore this question through the lens of variation theory, inter alia. Although esolangs may seem trivial, they deserve our attention since they can change the way we think about programming and language design. As Perlis (Perlis, 1982) puts it: Epigram 19: A language that doesn’t affect the way you think about programming, is not worth knowing. ## 2. Background In this section, we briefly survey the field of esolangs. We commence with the prototypical esolang, INTERCAL, in Section 2.1. After this, for the sake of convenience we cluster the languages into broadly related sets, considering esolangs that have a natural language syntax (Section 2.2), those with non-textual syntax (Section 2.3) and those with an exotic computational model (Section 2.4). We acknowledge that these characteristic properties are not mutually exclusive. Further, we acknowledge that other esolangs may not fall into any of these categories, but we hope this is sufficient for an imprecise ‘first cut’ at surveying the field. One key observation is that almost all esolangs have low-level semantics, in terms of primitive arithmetic operations on integer values, limited input/output facilities and primitive control flow. Higher-level facilities such as abstract data types, modularity and concurrency features are almost entirely absent. Another general observation is that the surface-level, concrete syntax of all esolang programs is highly unconventional. Typical esolang code does not look like mainstream code, indeed, it may not look like code at all (Cox and McLean, 2012). ### 2.1. INTERCAL We first discuss INTERCAL, since this is the archetype of esolangs. To the best of our knowledge, its language reference manual (Woods and Lyon, 1973) makes the first mention of ‘esoteric’ in relation to programming languages of this nature. The examples of INTERCAL programming which have appeared in the preceding sections of this manual have probably seemed highly esoteric to the reader unfamiliar with the language. With the aim of making them more so, we present here a description of INTERCAL. Like many subsequent esolangs, INTERCAL was devised by university students as a playful, humorous artifact. It has become ‘the longest-running and most convoluted joke in the history of programming language design’ (Raymond, 2010). Although the language initially had a minimal compiler and negligible source code corpus, it caught the attention of a small group of dedicated enthusiasts including high profile Computer Scientists like Raymond (Raymond, 1990) and Knuth (Knuth, 2011) who helped to popularize it. INTERCAL is not a well-formed acronym or abbreviation: confusingly The contraction is ‘for obvious reasons’, according to the language manual (Woods and Lyon, 1973). it stands for ‘Compiler Language With No Pronounceable Acronym’. The language was invented in 1972 by two Princeton students as a parody of the verbose imperative languages of the day. INTERCAL has unusual lexical elements, such as the use of the characters ¢ and $ as operators. There are also unconventional binary operations, such as bitwise interleavings of values. For these reasons among others, fairly standard arithmetic operations become complex and convoluted in INTERCAL. One of the (many) highly original features of INTERCAL is the PLEASE command modifier. The compiler requires occasional politeness, however excessive PLEASE s cause a compilation error. In a remarkable back-to-the-future moment, recent ChatGPT users have demonstrated similar politeness with AI prompts (Yuan et al., 2024). Bratishenko (Bratishenko, 2009) identifies the philosophy of INTERCAL as ‘technomasochism’, since programmers working with this esolang seem to derive pleasure from their painful software development experience. Error messages are highly unreadable, as Figure 1 illustrates, when the ick INTERCAL compiler is unable to parse a program correctly. <details> <summary>pics/ick.png Details</summary>  ### Visual Description ## Terminal Session Screenshot: Esolang Execution Attempt ### Overview The image is a screenshot of a terminal window, likely on a macOS system (indicated by the Apple logo). It shows a user attempting to execute a file named `fib.i` using a command called `ick`. The execution results in a multi-line error or status message in bright green text. ### Components/Axes * **Terminal Prompt (Top Line):** * **System Icon:** Apple logo () in green. * **Current Directory Path:** `~/Doc/esolangs/code` (displayed in blue). * **Version Control Status:** `git` followed by a branch icon and the branch name `main` (displayed in green). * **Command Prompt Symbol:** `>` (displayed in green). * **Executed Command:** `ick ./fib.i` (displayed in green). * **Program Output (Subsequent Lines):** * All output text is in a bright green monospaced font against a black background. * The output consists of three distinct lines of text. ### Detailed Analysis **1. Command Line Transcription:** ```  ~/Doc/esolangs/code git  main > ick ./fib.i ``` * **Path:** The user is in a directory named `code` within a folder `esolangs`, which is inside `Doc` in their home directory (`~`). * **Context:** The directory name `esolangs` suggests this is a project related to "esoteric programming languages." * **Command:** The command `ick` is being run on the file `fib.i` located in the current directory (`./`). The `.i` file extension is likely associated with the `ick` interpreter or a specific esoteric language. **2. Program Output Transcription:** ``` ICL999I NO SKELETON IN MY CLOSET, WOE IS ME! ON THE WAY TO 1 CORRECT SOURCE AND RESUBNIT ``` * **Line 1:** `ICL999I NO SKELETON IN MY CLOSET, WOE IS ME!` * This appears to be an error or status code (`ICL999I`) followed by a whimsical, poetic message. The phrase "NO SKELETON IN MY CLOSET" is idiomatic, often meaning there are no hidden secrets or past misdeeds. "WOE IS ME!" expresses sadness or lament. * **Line 2:** `ON THE WAY TO 1` * This line is ambiguous. It could indicate a process is underway, a target value (like the number 1 in a Fibonacci sequence, given the filename `fib.i`), or a state within the program's execution. * **Line 3:** `CORRECT SOURCE AND RESUBNIT` * This is a clear instruction to the user. It contains a typo: "RESUBNIT" is almost certainly meant to be "RESUBMIT." The message directs the user to fix the source code (`fib.i`) and run the command again. ### Key Observations * **Esoteric Language Context:** The combination of the directory name (`esolangs`), the unusual command (`ick`), the file extension (`.i`), and the cryptic, humorous output strongly indicates the user is working with an esoteric programming language (esolang). These languages are designed for experimentation, humor, or artistic expression rather than practical use. * **Error Handling Style:** The error message is not a standard system error. It is a custom, personality-driven message from the `ick` interpreter or the program itself, which is characteristic of many esolangs. * **Filename Hint:** The filename `fib.i` strongly suggests the program is intended to compute or relate to the Fibonacci sequence. * **Typo in Output:** The word "RESUBNIT" in the final line is a clear typographical error for "RESUBMIT." ### Interpretation This screenshot captures a failed attempt to run an esoteric program. The `ick` interpreter has analyzed the source file `fib.i` and rejected it, providing a creative error message instead of executing the code. * **What the data suggests:** The program `fib.i` contains a syntax error, logical flaw, or violates a rule of the `ick` language. The interpreter's response ("NO SKELETON IN MY CLOSET") might be a metaphorical way of saying the code is incomplete, lacks a required "skeleton" or structure, or doesn't contain the expected "bones" of a valid program. * **How elements relate:** The command (`ick ./fib.i`) is the action. The three-line output is the system's reaction, forming a complete narrative: 1) A lament about the code's state, 2) A vague status, and 3) A direct instruction for remediation. * **Notable anomalies:** The primary anomaly is the non-standard, poetic error message itself. The typo "RESUBNIT" is a minor but notable humanizing flaw in the interpreter's output. The phrase "ON THE WAY TO 1" is the most cryptic element; without knowledge of the `ick` language's semantics, it's unclear if this is a progress indicator, a reference to the Fibonacci sequence's start (0, 1, ...), or an internal state message. **In summary, the image documents a user's interaction with a whimsical esoteric programming tool. The factual content is the transcribed command and output. The underlying information is a snapshot of the trial-and-error process inherent to working with experimental and artistic programming languages.** </details> Figure 1. Typical INTERCAL compiler error message The C language version of the INTERCAL compiler improved its reach (Raymond, 1990). Now, INTERCAL is available on many open-source package management systems. For instance, you can brew install intercal on macOS or alternatively, apt install intercal on Ubuntu. We consider INTERCAL to be an archetypal esolang since it demonstrates foundational principles that define the genre, i.e. syntactic absurdity and a satirical stance toward conventional programming language design. Later esolangs share these playful characteristics. INTERCAL sparked amusement and curiosity among the broader software developer community, which continues to engage with esolangs more generally. ### 2.2. Natural Language-like Programming Languages Programming in natural language was an early ambition for language developers. Initial high-level languages like COBOL reflect this drive, to some extent. Perhaps the most ‘natural’ programming language today is Inform7, used for interactive text adventure games (Nelson, 2006). However, a large number of esolangs have program syntax that appears to be a structured form of natural language artifacts. Table 1 presents a few instances of this category of esolang. Table 1. Esolangs based on structured natural language patterns | Shakespeare Rockstar Chef | Elizabethan theatrical script 1980s song lyrics Cooking recipe | Thou art a red rose Let your love be 2 2g Chocolate | Open thy heart Shout your love Serves 1 | | --- | --- | --- | --- | | LOLCODE | Internet chat | I HAS A x R 2 | VISIBLE x | For such languages, although the syntax is natural, the fixed structure of the artifact means that programs can be parsed in a straightforward manner. The underlying computational model is generally reasonable, involving integers, simple arithmetic operations, assignments to local variables, conditional tests and basic imperative control flow. For example, Figure 2 shows the step-by-step execution of a Shakespeare fibonacci calculation. Characters are individual variables storing integer values. In Shakespeare, only two actors can be on the stage at once. Their dialogue involves assigning values to each other. The most complex part of Shakespeare is the representation of integer literal constants, involving complimentary and derogatory nouns (denoting +1 and -1 respectively) with every prefixed adjective doubling a value. So ‘a sweet red rose’ would be $2\times 2\times 1$ , whereas a ‘poisonous toad’ would be $2\times-1$ . <details> <summary>pics/esolangpark.png Details</summary>  ### Visual Description ## Screenshot: Shakespeare Programming Language IDE Execution ### Overview This image is a screenshot of a web-based Integrated Development Environment (IDE) for the esoteric programming language "Shakespeare," hosted on the "Esolang Park" platform. The interface shows a program titled "The Fibonacci Program." in mid-execution, displaying the code, the current state of variables, and the program's output. ### Components/Axes The interface is divided into three primary regions: 1. **Header/Toolbar (Top):** * **URL:** `esolangpark.vercel.app/ide/shakespeare` * **Site Logo & Name:** "Esolang Park" (top-left). * **Language Selector:** A button labeled "Shakespeare". * **Execution Controls:** A blue "Play" button, a "Step" button (icon with a vertical line and arrow), and a red "Stop" button. * **Timer:** A clock icon followed by the value `15` and the unit `ms`. * **Navigation/Help:** A link labeled "Read the esolang notes" with an arrow, followed by icons for a document, a question mark (help), a moon (theme toggle), and GitHub. 2. **Code Editor (Left Panel):** * **Title:** "Code Editor". * **Content:** Lines of code written in the Shakespeare Programming Language. The code uses color syntax highlighting (character names in green, keywords in purple, other text in black/orange). * **Visible Line Numbers:** 1 through 23. 3. **Visualization Panel (Right Panel):** * **Title:** "Visualization". * **Sub-sections:** * **Variable State (Top):** Two buttons labeled "King Lear" and "Imogen". A label "Answer to question:" with a red button displaying "no". Below this, three variable-value pairs are listed. * **User Input (Bottom-Left):** A text area with placeholder text "Enter program input here...". * **Execution Output (Bottom-Right):** A text area displaying the program's output string. ### Detailed Analysis / Content Details **A. Code Editor Content (Transcription of Visible Lines):** ``` 1 The Fibonacci Program. 2 3 Romeo, the nth fibonacci number. 4 Juliet, the (n-1)th fibonacci number. 5 King Lear, the absolute limit. 6 Imogen, the iteration counter. 7 Titania, the temporary value. 8 Cleopatra, a comma literal character. 9 10 11 Act I: Calculation. 12 13 Scene I: The initialization. 14 15 [Enter Cleopatra and King Lear] 16 Cleopatra: 17 You are the sum of the sweetest warm yellow... [text cut off] 18 19 King Lear: 20 Thou art the product of a beautiful green... [text cut off] 21 Thou art the sum of a sweet red rose and... [text cut off] 22 [Exit Cleopatra] 23 [Enter Juliet] ``` *Note: Lines 17, 20, and 21 are truncated in the image.* **B. Visualization Panel Data:** * **Variable States:** * `Romeo: 34` * `Juliet: 21` * `King Lear: 10` * **User Input:** Empty (placeholder text only). * **Execution Output:** `1,2,3,5,8,13,21,` ### Key Observations 1. **Program State:** The program is paused or has stopped execution. The variable values (`Romeo: 34`, `Juliet: 21`) correspond to consecutive Fibonacci numbers (21 is the 8th, 34 is the 9th if the sequence starts 1,1,2,3,5,8,13,21,34). 2. **Output Sequence:** The output `1,2,3,5,8,13,21,` is the Fibonacci sequence up to 21, with each number separated by a comma. The trailing comma suggests the program was interrupted before printing the next number (which would be 34, matching Romeo's current value). 3. **Limit Variable:** `King Lear` is set to `10`. Given the context, this likely represents the iteration limit or the index of the Fibonacci number to compute. The output shows 7 numbers, and the variables hold the 8th and 9th numbers, indicating the program may be near its limit. 4. **UI State:** The "Play" button is highlighted in blue, suggesting the program is ready to run or is paused. The "Answer to question: no" button is red, which may be a specific state or flag within the Shakespeare language execution model. ### Interpretation This screenshot captures a debugging or demonstration session of a Shakespeare program designed to generate Fibonacci numbers. The Shakespeare Programming Language uses theatrical metaphors: characters represent variables, and dialogue between them performs operations (e.g., "You are the sum of..." assigns a value). The data suggests the program has successfully computed and output the Fibonacci sequence up to 21. The internal state shows it has calculated the next number (34) and is holding the previous one (21). The limit variable (`King Lear: 10`) and the iteration counter (`Imogen`, though its value isn't displayed) control the loop. The program appears to be in a paused state, possibly after completing its main loop or awaiting further input. The empty user input field indicates no external data was provided for this run. The interface effectively visualizes the abstract state of an esoteric language, making its unconventional execution model more transparent. </details> Figure 2. Online Interpreter for Shakespeare programs Similarly in Chef, the ingredients are used to store literal values (with quantities) and these values are stored in variables, which are integer stacks, denoted as mixing bowls. The various actions of cooking (pour/blend/fold) involve computation on integer values in the bowls. <details> <summary>pics/mixingbowls.jpg Details</summary>  ### Visual Description ## Photograph: Kitchen Mixing Bowls and Utensils ### Overview The image displays a collection of four mixing bowls, each containing a kitchen utensil, arranged in a diagonal line from the upper-left to the lower-right on a dark, speckled kitchen countertop. The scene is a close-up, functional kitchen setup, likely during or after food preparation. No textual information, labels, or data charts are present in the image. ### Components The image consists of the following primary elements, listed from the top-left (background) to the bottom-right (foreground): 1. **Orange Bowl (Top-Left)** * **Material:** Opaque plastic. * **Color:** Bright orange. * **Shape:** Round, with a slightly flared rim. * **Utensil:** A spatula with a dark green handle and a grey head, resting inside the bowl with the handle pointing upward and to the right. 2. **Stainless Steel Bowl (Center-Left)** * **Material:** Polished stainless steel. * **Color:** Silver/metallic, highly reflective. * **Shape:** Round, deep. * **Utensil:** A black silicone spatula with a bright lime-green handle, resting inside the bowl with the handle extending out to the right. The bowl's interior reflects the surrounding environment, including a distorted image of the person taking the photo. 3. **Green Bowl (Center-Right)** * **Material:** Opaque plastic. * **Color:** Light green. * **Shape:** Round with two integrated side handles. * **Utensil:** A black silicone spatula with a light blue or pale mint-green handle, resting across the bowl with the handle extending out to the right. 4. **Clear Glass Bowl (Bottom-Right)** * **Material:** Transparent glass. * **Color:** Clear with a slight blue tint at the rim. * **Shape:** Round, medium depth. * **Utensil:** A solid stainless steel spoon, resting inside the bowl with the handle pointing upward and to the left. **Background Elements:** * **Countertop:** A dark (black or very dark grey) laminate or stone surface with a speckled, granite-like pattern of lighter grey and white flecks. * **Backsplash:** A wall covered in small, square, beige or light tan tiles arranged in a grid pattern. * **Cabinet:** A portion of a light wood-grain cabinet door with a vertical, brushed metal handle is visible on the far right edge. ### Detailed Analysis * **Spatial Arrangement:** The bowls are placed in a staggered, diagonal line. The orange bowl is furthest back and highest in the frame. The stainless steel bowl is in front of and slightly below it. The green bowl is in front of and below the steel bowl. The clear glass bowl is the closest to the viewer and lowest in the frame. This creates a sense of depth. * **Utensil Placement:** Each utensil is placed within its respective bowl. The handles of the three spatulas (in the orange, steel, and green bowls) all extend generally towards the right side of the image. The spoon in the glass bowl is oriented differently, with its handle pointing towards the upper-left. * **Lighting and Reflections:** The lighting appears to be ambient indoor light. The stainless steel bowl shows strong specular highlights and clear reflections of the room and the photographer. The glass bowl also shows reflections and refractions of the countertop pattern beneath it. ### Key Observations * **Material Variety:** The set includes three different bowl materials (plastic, metal, glass) and two primary utensil materials (silicone-headed spatulas, metal spoon). * **Color Coordination:** The utensil handles feature accent colors (dark green, lime green, light blue) that contrast with their black heads and the bowls they are in. * **Functional Setup:** The arrangement suggests a *mise en place* or a staging area for cooking or baking, where ingredients might be measured or mixed in separate bowls before being combined. ### Interpretation This photograph documents a common kitchen scene focused on preparation tools. The variety of bowl materials indicates different uses: plastic for general mixing, stainless steel for tasks requiring durability or temperature conduction, and glass for visibility or microwave use. The diagonal composition is practical, allowing all items to be visible and accessible on the counter. The presence of multiple spatulas suggests tasks involving scraping, folding, or mixing batters or sauces. The image conveys a sense of organized, active cooking in a domestic kitchen environment. </details> Figure 3. Set of mixing bowls, appropriate for the CHEF esolang In general, these textual languages have primitive imperative features, often lacking facilities like dynamic memory allocation and compound data structures. ### 2.3. Non-Textual Syntax While all esolangs feature unconventional syntax, some of them have entirely non-textual syntax. Two such languages are Whitespace and Piet. Both these languages feature relatively straightforward abstract machines. They are stack based with a sensible instruction set that has appropriate low-level operations. In each case, the only truly unusual aspect of the language is the syntax. Whitespace has only three lexemes, all of which are whitespace characters, i.e. space, tab and newline. Various combinations of these lexemes make up instructions and literal data. On the other hand, a Piet program is a bitmap image. There is a fixed palette of colours, each of which is available in three different shades. A two-dimensional program counter, known as the ‘direction pointer’ traverses the image from the top-left pixel and instruction execution takes place when the direction pointer crosses a colour boundary. The difference between colours and shades is used to perform a lookup in a two-dimensional opcode table, which has traditional stack-based operations. The executable properties of Piet mean that a program could be carefully recoloured or resized, without changing its semantics. In these languages, programs deliberately don’t look like programs. For Whitespace, code is invisible to the human eye. For Piet, code is a colourful image. This is a kind of steganography, hiding code in visual media. ### 2.4. Unconventional Computational Model While all esolangs feature unconventional syntax, one group of esolangs combines this with unconventional abstract machines. In theory, all of computation is built on the foundation of a strange machine, i.e. the Turing machine. As long as a computational framework can emulate the execution of a Turing machine, then it is Turing complete. Mateas and Montford (Mateas and Montfort, 2005) identify minimalist esolangs, which have a small set of operations and closely resemble Turing’s model of computation. The most well known language of this kind is Brainf*** (BF). The language has eight primitive operations (denoted by single characters) which mimic a Turing machine. There is a fixed length byte array, with operations to read and write to the current element of the array, to move left or right to an adjacent element, to jump to a different part of the program based on the value stored in the current element, and to do character I/O. Because of its minimal nature, BF programs can be executed with a tiny interpreter. However most BF programs that perform ‘interesting’ tasks are very long (like Turing machines). Turing’s assumption of an infinite-length tape leads many programmers to assume storage space is infinite and that execution time may be unbounded. In contrast, BF imposes strict static limits on storage (generally the array is 30KB in size). The Befunge esolang is somewhat similar to BF. Again, operations have a single character. Programs are laid out in a two-dimensional grid, rather than BF’s one-dimensional line. Direction operators are used to change the direction of the instruction pointer. There is an auxiliary stack for intermediate computation. Malbodge was intentionally designed to be the most difficult language in which to write code. It is named after Dante’s eighth circle of Hell. The abstract machines uses ternary bits. An instruction’s precise effect depends on its memory location. Code is automatically self-modifying. Effectively, a Malbodge program re-encrypts its source code after every instruction execution. As may be expected, there are relatively few extant Malbodge programs and most of these are synthesized from search-based code. Conway’s Fractan language (Conway, 1987) is a purely mathematical esolang. A program starts with an initial integer value $N$ and a fixed list of fractions $f_{1},f_{2},\ldots,f_{k}$ . Conway explains the abstract machine semantics as follows: You repeatedly multiply the integer you have at any stage (initially $N$ ) by the earliest $f_{i}$ in the list for which the answer is integral. Whenever there is no such $f_{i}$ , the game stops. He demonstrates a program that generates the sequence of prime integers, then another that computes successive digits of $\pi$ . Conway criticizes other programming languages as having problems that ‘stem from a bad choice of the underlying computational model’. ### 2.5. Discussion It is commonly accepted that computer languages do not need to be Turing complete; for instance, some domain-specific languages are not. However, many esolangs are Turing complete. Generally, they fall into the category of Turing tar-pits —a phrase coined by Perlis (Perlis, 1982). Epigram 54: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. Essentially, most programs are verbose and tricky to write. This was an explicit design goal of INTERCAL (Woods and Lyon, 1973) and remains true for other esolangs. Cox (Cox and McLean, 2012) considers various aspects of esolangs, presenting a philosophical and largely non-technical appreciation. We review further esolang literature in Section 8. ## 3. Appeal of Esoteric Languages Esolangs have an enduring sense of appeal to many computer scientists, particularly programming language designers. In this section, we explore the reasons for this popularity. The characteristics we analyse have more to do with the nature of the programmer, than of the programming language. Although it’s natural for one to reflect the other … ### 3.1. Playfulness The stereotypical hacker (in the classical sense of a computing enthusiast) possesses a genuine sense of playfulness. Raymond (Raymond, 2000) makes the following observation of this community of practice: We hackers are a playful bunch; we’ll hack anything, including language, if it looks like fun …Deep down, we like confusing people who are stuffier and less mentally agile than we are, especially when they’re bosses. There’s a little bit of the mad scientist in all hackers, ready to discombobulate the world and flip authority the finger – especially if we can do it with snazzy special effects. This playful anti-authoritarian attitude is perfectly captured by esolangs. On the surface, programs in such languages appear to be confusing and counterintuitive—highly ‘discombobulating’, as Raymond puts it. One way to define ‘play’ is an activity which is defined by the activity alone, and is performed to discover the outcome, rather than to achieve a pre-defined goal. In this sense, the playfulness of esolangs is significant. Really, esolangs are only appropriate for expressing ‘toy’ programs and simple algorithm implementations. For the most part, esolangs feature primitive IO, perhaps only supporting putchar and getchar functions with no higher-level libraries. As such, code written in esolangs is simple in terms of I/O, probably the kind of program required in coding competitions like the Code Olympics and the Advent of Code. This reinforces the sense of playfulness; many people attempt Advent of Code problems in esolangs. For instance, a google search for ‘advent of code in brainf***’ highlights a number of attempts, demonstrating a non-trivial intersection between people who like esolangs and people who enter coding competitions. Intcode is an esolang designed explicitly for Advent of Code in 2019; really it is a low-level instruction set for a simple virtual machine. We acknowledge that it is not a new educational idea to connect play and learning. For instance, the Logo turtle graphics language is a playful way for school-age learners to encounter geometry, maths and programming. Papert (Papert, 2002) introduces the notion of ‘hard fun’, which captures ‘hard challenging things to do, and complex artifacts to play with’. Further, play is experiential learning by discovery (Kolb, 2014). To players, the activity is key and the outcome is not necessarily important. Again, these factors are evident in esolangs. Esolangs preserve a ‘sense of fun’ in programming. Perlis, as quoted by Abelson and Sussman (Abelson and Sussman, 1996), states: I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun …I hope the field of computer science never loses its sense of fun. ### 3.2. Nostalgia It is often the case that experienced developers enjoy wearing ‘the hair shirt’ (Peyton Jones, 2003) which involves putting themselves through difficult experiences while developing supposedly more elegant code. This trend originated with Turing, who invented the notion of optimal coding, whereby he would situate instructions at precisely the best locations in memory to be executed with minimum delay in a rotary memory machine—the Pilot ACE had circulating mercury delay lines to store instructions. Whereas other early stored program electronic computers employed complex control circuitry to avoid needing to make these instruction placement calculations, Turing wanted to defer the complexity to the programmer. Campbell-Kelly records Turing’s thinking about using hardware interlocks to avoid the need for optimal coding (Campbell-Kelly, 2012) as being: …much more in the American tradition of solving one’s problems by means of much equipment rather than by thought. Again, this attitude harmonizes neatly with the legendary story of Mel the Hacker from Royal McBee, recorded in Eric Raymond’s jargon file (Nather, 1983), describing how Mel wrote optimal code that worked perfectly on a specific rotating memory machine due to the increment of a self-modifying instruction resulting in a jump at precisely the right moment in the program. This idea that programming should be challenging for humans, requiring significant mental effort, is a common one. The proportion of time spent thinking, relative to compiling or executing code, used to be much higher. Of course, in the early days of computers, compilation was much more expensive, perhaps an overnight job. The use of esolangs raises the level mental activity required for programming. For instance, no program was written in the Malbodge language for several years after it was designed, and the first correct program was machine-generated. The key takeaway here is the hacker instinct that programming ought to be difficult, and esolangs enforce this. By contrast, coding in mainstream languages is becoming progressively simpler. Tooling support is another reason why coding in mainstream languages is relatively straightforward. Many new developers use integrated development environments like Visual Studio Code, featuring syntax highlighting, autocorrection, large language model (LLM) hints, static checking etc. Such modern IDEs have minimal support for esolangs: LOLCODE on VS Code is a notable exception, featuring a syntax highlighting plugin—see Figure 4 for instance. Mostly developers working with esolangs just use a text editor and terminal compilation. <details> <summary>pics/vslol.png Details</summary>  ### Visual Description ## Screenshot: Visual Studio Code with LOLCODE Extension and Fibonacci Program ### Overview This image is a screenshot of the Visual Studio Code (VS Code) integrated development environment (IDE). The interface is split into two primary vertical panes. The left pane displays the marketplace details for a "LOLCODE" language support extension. The right pane shows an open code editor with a file named `fib.lol` containing a program written in the LOLCODE esoteric programming language, which calculates Fibonacci numbers. The overall theme is dark mode. ### Components/Axes The interface is divided into several key regions: 1. **Activity Bar (Far Left):** Vertical bar with icons for Explorer, Search, Source Control, Run and Debug, Extensions, and Account/Settings. 2. **Primary Sidebar (Left Pane):** Currently showing the "Extensions" view, focused on the "LOLCODE" extension details. 3. **Editor Group (Right Pane):** The main code editing area displaying the `fib.lol` file. 4. **Status Bar (Bottom):** A horizontal bar displaying editor state information. ### Detailed Analysis #### **Left Pane: LOLCODE Extension Details** * **Extension Icon:** A circular blue icon featuring a stylized, laughing cat face (a "LOLcat"). * **Extension Name:** `LOLCODE` * **Author:** `Arwin Neil Baichoo` * **Install/Update Stats:** A cloud icon with the number `5,` (likely indicating thousands of installs). * **Description:** `LOLCODE Language Suppo...` (truncated, likely "Support"). * **Action Buttons:** A blue `Uninstall` button and a checked `Auto Update` checkbox with a settings gear icon. * **Tabs:** `DETAILS` (selected), `FEATURES`, `CHANGELOG`. * **Details Section Content:** * **Title:** `LOLCODE Support for Visual Studio Code` * **Description:** `An extension for VS Code which provides support for the LOLCODE esoteric language.` * **Embedded Preview Image:** A smaller screenshot within the details showing another LOLCODE program example. #### **Right Pane: Code Editor (`fib.lol`)** * **File Path (Breadcrumb):** `C: > Users > js360t > fib.lol` * **Code Content (Line-by-Line Transcription):** ``` 1 HAI 1.2 2 3 BTW fibonacci calculation 4 I HAS A x ITZ 1 5 I HAS A y ITZ 1 6 I HAS A temp 7 I HAS A counter ITZ 0 8 I HAS A max ITZ 10 9 10 IM IN YR loop 11 temp R x 12 x R SUM OF x AN y 13 y R temp 14 VISIBLE y 15 16 IM OUTTA YR loop 17 18 19 20 21 KTHXBYE ``` * **Code Logic:** The program initializes two variables (`x`, `y`) to 1, sets a loop counter and a maximum value (10), then enters a loop. Inside the loop, it performs a standard Fibonacci sequence step: stores `x` in `temp`, sets `x` to the sum of `x` and `y`, sets `y` to the old `x` (from `temp`), and prints the new `y`. The loop structure (`IM IN YR loop` / `IM OUTTA YR loop`) is present, but the loop condition (e.g., based on `counter` and `max`) is not visible in the shown lines, suggesting it may be defined elsewhere or the snippet is incomplete. #### **Status Bar (Bottom)** * **Left Side:** Error/Warning indicators (`0` errors, `0` warnings). * **Right Side:** * Cursor Position: `Ln 12, Col 16` * Indentation: `Spaces: 4` * Encoding: `UTF-8` * End of Line Sequence: `CRLF` * Language Mode: `{} LOLCODE` * Remote Development indicator (icon). * Notifications bell icon. ### Key Observations 1. **Dual-Language Context:** The screenshot captures both the *meta* context (the VS Code extension that enables LOLCODE development) and the *application* context (an actual LOLCODE program). 2. **Esoteric Language Syntax:** The code uses LOLCODE's distinctive, English-like keywords (`HAI`, `BTW`, `I HAS A`, `ITZ`, `IM IN YR`, `VISIBLE`, `KTHXBYE`). 3. **Incomplete Loop Logic:** The visible code defines loop variables (`counter`, `max`) but does not show the loop control statement (e.g., `IM IN YR loop UPPIN YR counter TIL BOTH SAEM counter AN max`). The loop body is present, but the termination condition is not visible in the 21 lines shown. 4. **Active Editing State:** The cursor is on line 12, column 16, within the statement `x R SUM OF x AN y`, indicating the file is actively being edited. 5. **User Environment:** The file path `C: > Users > js360t >` reveals the Windows username `js360t`. ### Interpretation This image serves as a technical document illustrating the development environment for an esoteric programming language. It demonstrates: * **Tooling Support:** How niche languages (like LOLCODE) are supported in mainstream IDEs through community-built extensions, complete with syntax highlighting and language service integration. * **Language Pedagogy:** The `fib.lol` file acts as a simple, canonical example (Fibonacci sequence) used to showcase or learn the syntax and structure of LOLCODE. The comment `BTW fibonacci calculation` explicitly states its didactic purpose. * **Workflow Snapshot:** It captures a moment in a developer's workflow—viewing extension details while simultaneously editing a program that uses that extension. The presence of the extension's "Uninstall" button suggests it is already installed and active, enabling the syntax highlighting seen in the editor. * **Code Structure:** The program follows a basic imperative structure: initialization, loop, computation, output, and termination. The missing loop condition in the visible snippet highlights that code understanding often requires viewing more than a partial screen capture. </details> Figure 4. Visual Studio Code with the LOLCODE plugin in operation Further, many mainstream managed language runtimes feature dynamic safety checks, e.g. for out-of-bounds memory accesses. Even traditionally unsafe languages, like C, can be executed with address sanitizers or binary instrumentation to detect bugs. Esolang runtimes do not have these safety checks, by default. Another issue relates to AI-generated code. LLMs are notoriously helpful at generating reasonable code for mainstream languages. However AI synthesized code is less successful for esolangs, see Section 7. The upshot of all of this is, for programmers hankering for the lost ‘golden age’ of programming, when there were no fancy development environments or AI assistants, esoteric languages represent a viable way to return to this time and relive this experience. In some sense, this is a pre-Raphaelite attitude to programming, with value placed on complexity and attention to detail. ### 3.3. Sense of Belonging Language serves as a powerful marker of community and group identity. Fluency in a language often signifies inclusion within a particular discourse community. This is true not only for natural languages but also for constructed ones—consider, for instance, Creole languages or fictional tongues like Klingon. In all these scenarios, language functions as a social bond, connecting individuals through shared forms of expression and cultural identity. In recent programming practice, there has been a growing emphasis on localization—developing notations that reflect a range of ethnically diverse languages as a means of promoting inclusivity (Swidan and Hermans, 2023). Some esoteric programming languages also engage with this idea of cultural identity. For example, Cree# incorporates vocabulary from Nehiyawewin, the Plains Cree language, offering a unique intersection between programming and Indigenous linguistic heritage (Corbett, 2023). To the novice programmer, unfamiliar syntax and abstract concepts can feel confusing and discouraging. In contrast, experienced programmers often embrace this complexity, finding enjoyment and stimulation in the challenge. What may seem obscure or unconventional to a beginner can appear refreshingly creative and original to a seasoned practitioner (Cox and McLean, 2012). Esoteric programming languages, in particular, foster a sense of community—not necessarily through fluency in a single language, but through a shared appreciation for playful, cryptic syntax and unconventional algorithmic expression. This shared enthusiasm hints at a kind of cultic initiation, where an ‘inner circle’ of programmers engages with code not merely as a practical tool, but as a source of amusement, aesthetic pleasure, and intellectual play. Another key concept in esoteric practice is the idea of transmission, which is considered a critical feature of such traditions (Faivre, 1994). Unlike mainstream languages, which are typically acquired via textbooks and formal instruction, esolangs are learned through more elusive means: scattered resources, word-of-mouth exchanges, and personal initiation. This difficulty in access not only shapes the learning process but also contributes to a sense of mystique, reinforcing the allure of the esoteric. Nevertheless, the advent of the internet means it is now more straightforward to build a community around a constructed language (Gobbo et al., 2005). ### 3.4. Artistic Expression In his Mythical Man Month, Brooks (Brooks Jr, 1995) refers to the ‘sheer joy of making things’ as the primary motivation for the creative acts of programmers. Every program is an artifact, which may be viewed from different perspectives. Lonati et al (Lonati et al., 2022) enumerate six facets of programs as artifacts, dividing these into three pairs of contrasting features, namely: 1. notational artefact versus executable entity 1. human-made versus tool 1. abstract entity versus physical object Programs in esolangs emphasize: 1. the notational artefact, given the weird syntax 1. the human-made, given the ingenuity to construct the program 1. the abstract entity, given some higher-level semantics for the abstract machine of the particular esolang Knuth’s literate programming (Knuth, 1984) conveys a deep truth which almost all programming language creators have ignored—code is written for two utterly different readers: the compiler which acts physically on the code, and the human who reads the code to understand it. Another perspective, acknowledged by Knuth, is that code has an aesthetic value. Source code may be appreciated as art, cf. ‘The Art of Computer Programming’. In this case, the code itself is an artifact: generally (although not always) a visual object that can be enjoyed directly, by the viewer. There are some exhibits of software as art, for example at the Programming Language History museum. https://spectrum.ieee.org/art-of-code. However it’s not clear how much of these artistic displays are source code. Esoteric languages may be considered as an art form in some circles (Temkin, 2025). We might also mention ‘live coding’, where the programming itself is generating art (e.g. live music (Blackwell and Collins, 2005)). This is usually performative art, rather than artifact creation. More generally, usable live programming involves fluid code editing with immediate feedback (McDirmid, 2013). If artifacts can be interpreted as code, e.g. bitmap images as Piet programs, or 16th Century English plays as Shakespeare programs, can we interpret arbitrary artifacts as code? How does the real text of ‘Romeo and Juliet’ compute? Or is this a nonsensical question to ask? Certainly valid Shakespeare programs respect implicit syntactic restrictions, such as allowing only two actors on-stage at any given time. The idea of a program having multiple interpretations was demonstrated by Worth, who wrote a Chef program that can be interpreted as a ‘Hello world’ program and also interpreted as a viable cake recipe. https://web.archive.org/web/20230501044254/https://www.mike-worth.com/2013/03/31/baking-a-hello-world-cake/ ## 4. Pedagogic Value In earlier sections, we hinted at the value of esoteric languages with respect to learning programming. As already discussed, Papert’s notion of ‘hard fun’ is relevant here—esoteric languages are intriguing and may engage learners in different ways to grapple with the challenges of programming. We learn when we are having fun, and there is no need to be embarrassed about this. Early exposure to multiple programming languages is widely considered to be beneficial to novice programmers (Denny et al., 2022). Seeing the same underlying concept (e.g. a counted loop) expressed in differing contexts is conducive to learning; this is the basis of variation theory (Thuné and and, 2009). Concept transfer from one programming language to another is extremely important, helping students to enrich their notional machine models. Identifying true- and false-carry over concepts is highly relevant for mainstream languages, often when they have broadly similar syntax (Tshukudu and Cutts, 2020). For esoteric languages with unconventional syntax, instead the deep underlying conceptual transfers are enforced, which only have semantic (not syntactic) correspondence. There are concrete instances of esolang usage in education. Chef was used in the ‘LCC 2700 Introduction to Computational Media’ course at Georgia Technology from 2005 onwards. https://www.dangermouse.net/esoteric/chef.html There are many other beneficial learning outcomes when novice programming students are exposed to esolangs. One obvious learning outcome is the reinforcement of Dijkstra’s dictum that GOTO is ‘considered harmful’ (Dijkstra, 1968). For instance, some esolangs only have a GOTO style construct, such as Shakespeare’s Let us proceed to Scene N. Shakespeare code is sadly often spaghetti code. Another positive learning outcome is the realisation that syntax is merely the surface form of a program, and can easily be altered. The bizarre or unexpected nature of much esolang syntax foregrounds the fact that the surface ‘look-and-feel’ of code is flexible. Learners begin to understand that what really matters is the underlying structure and semantic content behind the syntax. This liberates novice programmers from being overly attached to any one language (language tribalism), instead promoting a more conceptual, language-agnostic approach to software development. Many esolangs pare away the conveniences of high-level languages and expose directly the underlying computational model. The abstract machine may be some variant of a Turing machine, or some alternative. The programmer is forced to consider how control flow, program state, and logic work at a low level. This understanding is highly valuable, as it concretizes what’s happening when programs execute. There are additional learning outcomes for more advanced (i.e. non-novice) students. For instance, most esoteric languages are of the size and scale that would be suitable for a toolchain implementation as a student project. Students would have a more rounded education if they designed an esolang and then implemented it, using appropriate language engineering tools. This ‘toe-in-the-water’ experience would be relatively straightforward to support, and would introduce learners to the issues around what makes a good language. The key critical thinking exercise here would introduce students to at least a few basic ideas on how assess what is desirable in a programing language. Finally, for programming educators, esolangs offer the opportunity to experience similar levels of frustration as the average novice programmer does with a mainstream language. You might be adept at expressing quicksort in a handful of lines of Haskell, but what happens when you try to write a sorting algorithm in an esolang? We might be able to enhance our empathy as educators, as we relive the agony of debugging cryptic fragments of programs we hardly understand. So, at first glance esolangs might seem silly or impractical, but they offer serious educational value. They demonstrate that programming is not just about learning syntax or toolchains, but about reflecting critically about what we do when we write programs. ## 5. Designing New Esoteric Languages In this section, we discuss the design and development of esolangs. First we examine the kinds of people who create new esolangs (Section 5.1) and then we move on to consider their reasons for creating such languages (Section 5.2). ### 5.1. Who Develops Esolangs? #### 5.1.1. Mostly Students? Many esolangs were designed by Computer Scientists during their university studies. For instance, the INTERCAL language was created by two Princeton University students: Woods and Lyon. The Whitespace language was created by two undergraduates at Durham University: Brady and Morris. Further, the Shakespeare language was created by students Åslund and Wiberg as a coursework project submission in their Compilers course at Royal Institute of Technology in Stockholm. https://web.archive.org/web/20220721085340/http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html These instances demonstrate that the simplicity of esolangs means their implementation is tractable as a one- or two-person programming exercise, for advanced undergraduate students. Following Brooks’ ‘plan to throw one away’ principle of software engineering (Brooks Jr, 1995), some student esolang developers have proceeded to develop more serious, mainstream languages in later life. For example, Brady (of Whitespace fame) later invented Idris, a dependently-typed functional language (Brady, 2013). Similarly, Morgan-Mar is a serial inventor of esolangs, including Chef and Piet. https://www.dangermouse.net/esoteric/ #### 5.1.2. Mostly Males? Similarly to common perceptions regarding mainstream languages, it seems that the majority of esolang designers are males. This is based on a cursory analysis of designer names, with some implicit cultural assumptions. A more formal analysis would be required to verify this claim. However it generally concurs with the work of Hermans on feminism in programming languages (Hermans and Schlesinger, 2024), as she notes that ‘exclusion of women from technology is both a cause and a result of a gendered interpretation of what programming is and what contributions matter’. Hermans notes that valuing ‘hard’ and employing ‘difficult tools that not everyone can use’ are both male-dominant characteristics, which again, might align with the prevailing trends of esolangs. Beckwith and Burnett (Beckwith and Burnett, 2004) identify how male and female developers approach end-user programming environments in different ways. For instance, low self-efficacy (less common in males) attributes failure in difficult tasks to personal lack of ability. This effect might be exacerbated in the complex syntactic surfaces of esolangs. On the other hand, alternative programming paradigms, such as programming as story telling has been shown to appeal more to female students (Kelleher, 2008). It is certainly the case that some esolangs (particularly the textual ones where programs don’t look like programs) follow the story telling pattern, in some sense. ### 5.2. Why Develop an Esolang? #### 5.2.1. Comedy The most commonly asserted reasons for developing an esolang involve humor. INTERCAL is essentialy a parody of mainstream languages from the 1970s. The courteous PLEASE DO command is a not-so-subtle criticism of the imperative nature of FORTRAN and the verbose syntax of COBOL. The INTERCAL manual (Woods and Lyon, 1973) is written in a breezy, comedic style. For example, the first paragraph states: ‘Any resemblance of the programming language portrayed here to other programming languages, living or dead, is purely coincidental’. The Whitespace language was publicly announced as an April Fool’s joke on the Slashdot developer news site on 1 April 2003. The language itself was an implementation of an original idea suggested by Stroustrup as an April Fool some five years earlier (Stroustrup, 1998). From these two cases, we acknowledge that esolangs are not particularly serious in general. The online web comic xkcd also features esolangs, see Figure 5. <details> <summary>pics/xkcd2309.png Details</summary>  ### Visual Description ## Comic Strip: Programming Language Legal Dispute ### Overview This is a four-panel comic strip in a minimalist black-and-white stick-figure style. It depicts a humorous narrative about a programmer who creates a new programming language, faces legal action, and attempts to circumvent the ruling with a technically compliant but absurdly impractical design. The comic satirizes both overly complex programming language design and legal technicalities. ### Components/Axes - **Format**: Four sequential panels arranged horizontally. - **Characters**: Two stick figures. One is the programmer (holding a laptop in panels 1-2, holding a book/folder in panels 3-4). The other is an off-screen interlocutor (represented only by dialogue bubbles with jagged tails indicating speech from outside the frame). - **Visual Elements**: Simple line drawings. The programmer's laptop shows a generic code editor interface in the first two panels. The book/folder in the last two panels is blank. - **Text**: All text is in uppercase, handwritten-style font within speech bubbles. Sound effects ("DAMMIT.") are written directly in the panel. ### Detailed Analysis / Content Details **Panel 1 (Leftmost):** - **Scene**: Programmer stands holding an open laptop. - **Dialogue (Programmer)**: "I'VE DEVELOPED A NEW PROGRAMMING LANGUAGE!" - **Dialogue (Off-screen)**: "DIDN'T A JUDGE ORDER YOU TO STOP DOING THAT?" - **Visual Note**: The off-screen speaker's bubble has a jagged tail pointing to the right edge of the panel. **Panel 2:** - **Scene**: Programmer looks triumphant, still holding the laptop. - **Dialogue (Programmer)**: "HIGHER COURT THREW OUT THE RULING! I'M BACK, SUCKERS!" - **Sound Effect**: "DAMMIT." written near the right edge, with small lines indicating it's an exclamation from the off-screen character. - **Visual Note**: The programmer's posture is more animated, suggesting excitement. **Panel 3:** - **Scene**: Programmer now holds a closed book or folder, looking reassuring. - **Dialogue (Programmer)**: "BUT I PROMISE IT'S GOOD THIS TIME! JUST NORMAL CODE. GOOD CLEAN SYNTAX. NOTHING WEIRD." - **Dialogue (Off-screen)**: "OKAY..." - **Visual Note**: The off-screen character's bubble has a hesitant, trailing tail. **Panel 4 (Rightmost):** - **Scene**: Programmer holds the book/folder and gestures with one hand. - **Dialogue (Programmer)**: "EXCEPT THE ONLY VARIABLE NAME IS 'X.' TO REFER TO DIFFERENT VARIABLES YOU HAVE TO WRITE 'X' IN DIFFERENT FONTS." - **Dialogue (Off-screen)**: "I'M CALLING THE COURT." followed by "MAYBE WE CAN APPEAL." - **Visual Note**: The final off-screen dialogue is split into two bubbles, indicating a resigned, two-part statement. ### Key Observations 1. **Narrative Arc**: The comic follows a clear sequence: announcement → legal conflict → resolution/return → new absurd condition → immediate rejection. 2. **Humor Mechanism**: The joke relies on a bait-and-switch. The programmer claims to have a "normal" language after legal trouble, but the sole rule (using fonts to distinguish variables) is a parody of overly clever or impractical language features. 3. **Visual Storytelling**: The programmer's prop changes from a laptop (active coding) to a book/folder (presenting a specification), visually signaling a shift from action to explanation. 4. **Pacing**: The off-screen character's reactions progress from questioning ("Didn't a judge...") to reluctant acceptance ("Okay...") to immediate legal retaliation ("I'm calling the court."), driving the comedic timing. ### Interpretation This comic is a satire targeting two interconnected themes: 1. **Programming Language Design**: It mocks the creation of languages with gimmicky or unnecessarily complex syntax rules that prioritize novelty over usability. The "different fonts for the same variable name" idea is an extreme example of a feature that is technically possible but practically unusable, highlighting the difference between theoretical cleverness and practical engineering. 2. **Legal and Technical Loopholes**: The narrative humorously explores the idea of complying with the letter of a legal ruling while violating its spirit. The programmer technically stops "doing that" (presumably creating bad languages) by creating a language with one absurd rule, which is a different kind of "bad." The off-screen character's immediate move to involve the court again suggests that such loopholes are transparent and frustrating. The comic suggests that true innovation in technical fields requires genuine improvement, not just clever circumvention of constraints. The programmer's enthusiasm is framed as misguided, while the off-screen character represents a pragmatic, if exasperated, voice of reason. The final panel's punchline underscores that some ideas are so fundamentally flawed that they invite immediate rejection, regardless of their technical compliance with previous agreements. </details> Figure 5. Hypothetical esolang suggestion from xkcd.com webcomic, number 2309 (CC BY-NC 2.5 Randall Munroe) Tiwari et al. (Tiwari et al., 2024) explore how humor is great motivation for software developers. Further, Kuutila et al. (Kuutila et al., 2024) analyse reddit posts to characterize programming humor. They show that ‘things that violate accepted patterns in a non-threatening way are perceived to be humorous’—attributes that clearly apply to esolang programs. However the sheer number of esolangs and the efforts involved in supporting them lead us to believe that there are other, deeper motivations for esolang development. #### 5.2.2. Challenge Next we consider the skills of working within very tight self-imposed constraints, which are stock-in-trade for the experienced developer. For esoteric languages, programs need to be written differently, in an unconventional syntax and structure. Constraints are ever-present, and in some cases programs are practically impossible to write, e.g. for the Malbodge language. We discussed these issues earlier, in Section 3 when we were considering the attraction of writing code in an esolang. Similar challenges will apply to develop an esolang, whether or not that language is self-hosting. Developers report that challenging problems are a key intrinsic motivation for their productivity (Hall et al., 2008). However again, this aspect on its own does not seem to account for the wide variety of esolangs and the intense development effort. #### 5.2.3. Creativity Finally, there is the attraction of creating a programming language ‘of one’s own’. Constructing an esolang permits the programmer to enjoy the luxury of a ‘break from the bland, bloated multiparadigm languages with imperative roots’ (Kneusel, 2022). This facility of expression, of ‘speaking code’ (Cox and McLean, 2012), is a powerful motivation for people to generate their own, custom esolangs. As we note in Section 4, creating an esolang gives excellent opportunity for students to reflect on what make a good programming language, and to identify tradeoffs in language design. After all, it feels as if esolangs are probably designed in exactly the same way as many widely used languages, i.e. for the convenience of the language designer rather than of the end-user programmer. Having considered the reasons why people develop esolangs, which are mostly to do with creative exploration and experimentation, in the next Section we will move into a more general discussion about motivations for designing any programming language. ## 6. Reasons for Developing a New Programming Language As we study the field of esoteric programming languages, we are confronted with a question that relates to more general programming language philosophy: Why does a person choose to design and develop a new programming language? Can we identify a set of overarching motivations for the construction of new programming languages? Here we are using our analysis of esolangs to reflect on wider aspects of programming language design. In this section, we suggest five generic themes pertaining to programming language design motivation: 1. Expressivity 1. Efficiency 1. Education 1. Economy 1. Exploration We consider each of these themes in detail below, providing example mainstream programming languages in each case. We recognize that some languages may have multiple design motivations. ### 6.1. Expressivity Steele (Steele, 1999) beautifully illustrates the notion of ‘growing a language’ with increasing expressive power, which enables succinct description of complex concepts. One key motivation for developing a new language is the need for expressive power. Of course, computability theory tells us we could all write in Church’s $\lambda$ -calculus and express any computation we like, but programs would be very long and unwieldy, and programming would be complex and unenjoyable, if not intractable. More expressive notational systems allow higher-level programs to be written. This was the original motivation for early high-level languages like Fortran, Cobol and Lisp. This is still the motivation for more modern high-level languages like Clojure or Prolog. Jones and Bonsignour note that a programmer can write a fairly constant number of lines of code per hour, regardless of the language used (Jones and Bonsignour, 2011). So a more expressive language should enable programmers to be more productive. They conclude that ‘the overall effort associated with coding and testing are much less significant for high-level …languages than for …low-level languages’. ### 6.2. Efficiency Low-level systems implementation languages like C were developed, at least originally, to map closely to the underlying hardware and enable efficient code generation. As Ritchie puts it, C is ‘a simple and small language, translatable with simple and small compilers. Its types and operations are well-grounded in those provided by real machines’ (Ritchie, 1996). C has an enduring popularity (Kell, 2017). More modern systems languages like Rust and Zig also explicitly aim for efficient execution of target code as a primary goal. ### 6.3. Education Another reason for developing a new language is for the purposes of programming education. Languages designed explicitly for novice learners include Grace (Black et al., 2013) although this has not been adopted widely. More venerable examples of educational languages include Logo and BASIC. Scratch and Alice are instances of graphical languages with non-traditional syntax for school-age learners. Hedy (Hermans, 2020) is a recent programming language that is aimed at novice learners, which has a gradually increasing syntax and semantics, to accommodate an incremental concept inventory and learning style. However, it is noteworthy that no mainstream industrial strength languages One reviewer kindly pointed out that Pascal might be an exception here. were explicitly designed for educational use, or with respect to pedagogical principles (Kölling, 2024). Further, initially simple industrial languages accumulate new features throughout their lifetime, generally measured in decades (Favre, 2005). ### 6.4. Economy Some languages are commercial imperatives—needed to satisfy economic ends. The language that springs to mind most readily is C#, originally conceived as a ‘direct rival’ to the Java ecosystem, which seemed to be a ‘deep challenge to Microsoft’ (Syme, 2020). ### 6.5. Exploration Some programming languages are designed primarily as an intellectual exercise, seeking to explore a new area or evaluate a new concept. The Haskell language (Hudak et al., 2007) may well fall into this category. In his HOPL presentation of this paper, Peyton Jones explains how Haskell was intended to ‘avoid success at all costs’ which means the relatively small user-base are happy for the language to be ‘nimble’ in terms of feature updates. ### 6.6. Esolang Motivations Earlier, in Section 5.2, we discussed why people are motivated to design and develop new esolangs. In this section, we want to locate those identified motivations within the five point hierarchy of programming language design motivation outlined above (the five ‘E’s). For many of the motivations, it feels like esolangs have diametrically opposed objectives. In terms of expressivity, esolangs deliberately use obscure syntax and limited constructs, making it difficult to express many algorithms in a meaningful and elegant manner. An esolang pares down the available operations to a minimal set, unlike most mainstream languages. In terms of efficiency, while esolang semantics frequently map directly onto a low-level computational model, such a model is generally quite distinct from mainstream computer architecture, making execution less efficient. In terms of education, esolangs are explicitly not designed for novice programmers. For instance, the INTERCAL language manual (Woods and Lyon, 1973) states: ‘Since it is an exceedingly easy language to learn, one might expect it would be a good language for initiating novice programmers. Perhaps surprising, than, is the fact that it would be more likely to initiate a novice into a search for another line of work’. In terms of economy, esolangs are not commercially viable in any sense. No meaningful software is developed in esolangs and no esolang toolchain is available on a commercial basis. Perhaps the only people who might benefit financially from esolangs are book authors and publishers. For instance, MIT Press has a current esolang title available (Cox and McLean, 2012) and another one forthcoming (Temkin, 2025). Therefore, it seems that the majority of esolangs fall into the curiosity-driven, exploratory category. They seek to experiment with syntax or semantics in unconventional ways, pushing the boundaries of programming in some sense. ## 7. AI and Esolangs No research work is complete nowadays without a consideration of the implications of AI on the topic. In this section we briefly discuss how AI might be useful for esolangs. ### 7.1. Esolang Code Synthesis Could an AI-based large language model (LLM) synthesize correct code to solve a specified problem in a given esolang? On the one hand, LLM-generated code seems to work well for mainstream languages (Li et al., 2022; Liu et al., 2023). On the other hand, our initial experiments suggest that ChatGPT and Llama.cpp do not create syntactically correct code for esolangs including INTERCAL, Shakespeare, Whitespace and Piet. While the textual conversation surrounding the generated code sounds plausible, the code itself generally does not compile and often appears to contain fundamental syntactic flaws. For example, Figure 6 shows a Piet program generated by ChatGPT, responding to our prompt to ‘produce a Piet program to calculate the first 10 Fibonacci numbers’. The resulting image cannot be parsed by the npiet interpreter. <details> <summary>code/fib-piet.png Details</summary>  ### Visual Description ## Diagram: Modular Block Pathway System ### Overview The image displays a schematic diagram of interconnected colored blocks arranged on a white background, enclosed within a black border composed of small, uniform squares. The diagram appears to represent a conceptual model of pathways, connections, or a modular system, possibly for illustrating flow, network topology, or a puzzle-like structure. There is no textual information, labels, axes, or legends present. The information is conveyed entirely through the spatial arrangement, color, and relative positioning of the geometric blocks. ### Components The diagram consists of the following visual elements: 1. **Border:** A continuous frame made of small, dark gray/black squares, creating a grid-like boundary around the entire composition. 2. **Blocks:** The primary elements are rectangular and square blocks of solid colors. Each block is subdivided by thin black lines into smaller, uniform square units, giving them a tiled or modular appearance. 3. **Color Palette:** The blocks use a distinct set of colors: green, red, pink/magenta, orange, yellow, lime green, blue, teal, and dark blue. 4. **Spatial Layout:** The blocks are arranged in three primary groupings or pathways within the white interior space. ### Detailed Analysis The blocks are organized into three distinct, non-overlapping pathways or structures: **1. Upper Diagonal Pathway (Top-Left to Mid-Right):** * **Starts** at the top-left with a large **green** square block (approx. 2x2 units). * Connects diagonally downward to the right through a sequence of blocks: * A **red** block (1x1 unit). * A **pink** block (2x2 units). * An **orange** block (2x2 units). * A **yellow** block (2x2 units). * A **lime green** block (2x2 units). * A **blue** block (2x2 units). * Ends with a **dark blue** block (2x2 units) at the mid-right edge of the diagram. * **Trend:** This pathway forms a descending staircase pattern from the upper-left corner towards the center-right. **2. Middle Horizontal & Vertical Pathway (Center-Left to Center-Right):** * **Starts** below the upper pathway with a vertical **pink** block (2x1 units). * Connects to a horizontal **pink** block (3x2 units) extending to the right. * Continues rightward through: * A **red** block (2x2 units). * An **orange** block (2x2 units). * A **yellow** block (2x2 units). * Turns upward with a **teal** block (2x2 units). * Ends with a **green** block (2x2 units) positioned above the teal block. * **Trend:** This pathway forms a roughly "L" or hook shape, moving horizontally right and then vertically up. **3. Lower Vertical Structures (Bottom-Left to Bottom-Right):** These are three separate, vertical columnar structures. * **Left Column:** A single vertical **blue** column (2 units wide x 6 units high). * **Center Column:** A wider vertical **blue** structure (4 units wide x 6 units high), appearing as a 2x3 grid of larger blue blocks. * **Right Column:** A composite vertical structure (2 units wide x 6 units high). * The left half is a continuous **blue** column. * The right half is segmented by color from top to bottom: **red** (2 units), **orange** (2 units), **yellow** (2 units). ### Key Observations * **No Text or Data:** The image contains zero textual information, numerical data, labels, or legends. It is a purely visual, abstract diagram. * **Color as Identifier:** Color is the sole differentiator between block types or components. There is no explicit key explaining what each color represents. * **Modular Design:** All blocks are built from a common grid of smaller squares, suggesting a system based on standardized units. * **Disconnected Pathways:** The three main groupings (Upper, Middle, Lower) do not appear to be physically connected to each other. They exist as separate entities within the frame. * **Spatial Grounding:** The upper pathway occupies the top third, the middle pathway the central third, and the lower structures the bottom third of the diagram's interior space. ### Interpretation This diagram is an abstract representation of a system, not a chart of empirical data. Its meaning is open to interpretation, but the visual language suggests several possibilities: 1. **Network or Flow Diagram:** The colored blocks could represent nodes or modules, and their adjacency implies a connection or pathway for information, material, or process flow. The different colors might signify different types of nodes, functions, or states. 2. **Puzzle or Game Board:** The arrangement resembles a puzzle where the goal might be to connect specific colored blocks or navigate a path. The separate lower structures could be starting points, endpoints, or resource pools. 3. **Conceptual Model of Organization:** It could illustrate concepts like departmental structures (colors as teams), workflow stages, or data architecture, where the spatial layout shows relationships and hierarchies. 4. **Emphasis on Modularity and Composition:** The consistent use of a grid-based building block highlights themes of construction, scalability, and systematic design. The separation of the three pathways might indicate independent subsystems within a larger whole. **Notable Anomaly:** The lack of any connecting lines between the three major pathways is significant. If this is meant to represent a single integrated system, the diagram is incomplete. If it represents three independent systems, their juxtaposition within the same frame invites comparison or suggests they are part of a larger, unseen context. **Conclusion:** The image provides structural and relational information but no factual data. To extract specific meaning, one would need external context explaining the symbolism of the colors and the intended purpose of the diagram (e.g., "Blue blocks represent databases, red blocks represent user inputs..."). Without that, it remains a well-defined but semantically open schematic of modular components. </details> Figure 6. AI-synthesized Piet Fibonacci program, which contains syntax errors One reason why AI might be poor at synthesizing esoteric code is the limited training set of online code examples, in contrast to mainstream languages like Python and JavaScript (Wang et al., 2024; Twist et al., 2025). AI will not ‘render software engineering irrelevant’ (Kang and Shaw, 2024). This is notably true for software development in esolangs. The obscurity of esolangs means they are significantly under-represented in most LLM training corpora. ### 7.2. Esolang Creation Could an AI model generate an interesting esolang, either a definition or a language implementation? We conducted some brief experiments with ChatGPT, but the results were not particularly impressive. Generated languages were not Turing complete, i.e. they did not define control flow properly. Further, example programs were not well-formed. Figure 7 shows an example of a constructed language with a syntax based on musical notation but the language definition is both incomplete and ambiguous. Further, this idea is highly unoriginal since a music-based esolang is already available, named Velato (Temkin, 2009). <details> <summary>pics/ai1.png Details</summary>  ### Visual Description ## Screenshot: Chat Interface with Esoteric Programming Language Concept ### Overview The image is a screenshot of a text-based chat interface, likely from an AI assistant platform. It displays a two-part conversation: a user query and an AI-generated response introducing a concept for an esoteric programming language. The interface is clean, with messages contained in rounded bubbles against a plain white background. ### Components/Axes The image is segmented into three distinct spatial regions: 1. **Header / User Query Region (Top-Center):** * A light gray, rounded message bubble containing the user's prompt. * **Text Content:** `can you generate an interesting esoteric programming language?` 2. **Main Content / AI Response Region (Center-Left):** * A plain text response from the AI, left-aligned below the user's bubble. * A thin, horizontal gray line separates the introductory text from the language details below. * **Text Content (above line):** `Absolutely! Here's a quirky and interesting esoteric programming language (esolang) concept for you:` 3. **Footer / Language Detail Region (Bottom-Left):** * The core information about the proposed language, formatted for emphasis. * **Text Content:** `💎 Language Name: "MUSE" (Musically Unstructured Symbolic Expressions)` * **Formatting:** The line begins with a blue diamond emoji (💎). The text `Language Name: "MUSE"` is in bold font. The parenthetical text `(Musically Unstructured Symbolic Expressions)` is in regular font and provides the acronym expansion. ### Detailed Analysis The textual information is presented in a clear, hierarchical structure: * **User Request:** A direct, open-ended question asking for the generation of an "interesting esoteric programming language." * **AI Acknowledgment & Framing:** The AI confirms the request ("Absolutely!") and frames its response as a "quirky and interesting" concept, using the common abbreviation "esolang." * **Language Concept Presentation:** * **Name:** "MUSE" * **Acronym:** Musically Unstructured Symbolic Expressions * **Visual Cue:** The use of the diamond emoji (💎) serves as a visual bullet point or icon to draw attention to the language name. ### Key Observations * The conversation follows a standard query-response pattern common in AI chat interfaces. * The AI's response is structured to be engaging, using adjectives like "quirky" and "interesting" to match the user's request. * The language concept is presented with a memorable, thematic name ("MUSE") and a backronym that hints at its potential design philosophy (musical, unstructured, symbolic). * The formatting (bold text, emoji, horizontal rule) is used effectively to organize information and highlight the key output—the language name. ### Interpretation This screenshot captures a moment of creative collaboration between a user and an AI. The user's query is a prompt for creative ideation within a specific technical domain (esoteric programming languages). The AI's response demonstrates an ability to: 1. Understand and acknowledge the request. 2. Generate a novel concept that fits the "esoteric" category. 3. Present the concept in a structured and appealing format. The proposed language "MUSE" suggests a design that might interpret code as a form of musical or symbolic expression, potentially prioritizing creativity or obfuscation over practical utility, which is a hallmark of many esolangs. The interaction itself is a meta-example of using an AI tool to brainstorm another tool, highlighting the role of such systems in augmenting human creativity. The clean, text-focused interface design prioritizes the content of the conversation over visual distraction. </details> <details> <summary>pics/ai2.png Details</summary>  ### Visual Description ## Technical Document: MUSE Programming Language Concept ### Overview The image presents a conceptual description of **MUSE**, a musically inspired esoteric programming language (esolang). The document outlines the core idea and fundamental principles of the language, where musical notation serves as the primary syntax for programming operations. ### Components/Axes The document is structured into two main sections, each introduced by a musical icon and a bold heading: 1. **Section 1: Concept** * **Icon:** A musical note symbol (♪). * **Heading:** `Concept:` * **Content:** A paragraph defining MUSE. 2. **Section 2: Core Principles** * **Icon:** A treble clef symbol (𝄞). * **Heading:** `Core Principles:` * **Content:** A bulleted list of seven principles. ### Detailed Analysis / Content Details **Full Text Transcription:** **♪ Concept:** **MUSE** is a **musically inspired esolang** where **musical notation** is used as the primary syntax for programming. Every note, rhythm, and dynamic symbol translates into logic or data operations. Think of it like programming via sheet music. **𝄞 Core Principles:** * **Notes** are operations. * **Octaves** determine scope. * **Key signatures** set global flags or modes. * **Time signatures** affect control flow logic (e.g., loops). * **Rests** are pauses (NOPs). * **Dynamics (p, f, ff, etc.)** influence memory usage or data size. * **Chords** represent parallel execution. ### Key Observations * **Direct Mapping:** The language establishes a direct, one-to-one conceptual mapping between standard musical notation elements and core programming constructs. * **Scope of Analogy:** The analogy extends beyond simple commands (notes) to encompass structural elements (key/time signatures), execution flow (rests, chords), and data properties (dynamics). * **Esolang Nature:** It is explicitly defined as an "esolang," indicating it is designed more for conceptual exploration, creativity, or challenge rather than practical, general-purpose software development. * **Visual Presentation:** The use of musical icons (♪, 𝄞) as section markers visually reinforces the core theme. Key terms within the text (e.g., **musically inspired esolang**, **Notes**, **Octaves**) are bolded for emphasis. ### Interpretation The document describes a programming paradigm that uses the rich, structured language of music as its foundation. This is not merely a cosmetic theme; it proposes a functional isomorphism where musical concepts have precise computational meanings. * **What it suggests:** MUSE frames programming as a compositional act. Writing a program becomes analogous to composing a piece of music, where the "score" is the source code. This could potentially offer a novel, intuitive, or artistic way to think about algorithm structure and data flow for those familiar with music theory. * **Relationships between elements:** The principles show a hierarchical and relational structure. For example, **Key Signatures** (global modes) and **Time Signatures** (control flow) set the overarching context within which individual **Notes** (operations) and **Chords** (parallel tasks) are executed. **Dynamics** modify the properties (memory/data size) of the operations. * **Notable implications:** The mapping of **Chords** to parallel execution is particularly insightful, as it leverages the inherent simultaneity of musical chords to represent concurrent processes. Similarly, using **Rests** as NOPs (No-Operation instructions) is a clever and direct translation. The language's design implies that the rhythm and structure of the music directly dictate the program's logic and performance characteristics. </details> Figure 7. Excerpt of user interaction to develop an example esolang with ChatGPT While there are some online tools for synthesizing constructed languages (e.g. https://vulgarlang.com for fantasy novels), these work based on user-defined parameters and employ a pseudo-random algorithm (rather than an AI model) which incorporates a definite notion of linguistic grammar. ## 8. Related Work Landin discusses the ‘next 700 programming languages’ (Landin, 1966), optimistically stating that ‘we must systematize their design so that a new language is a point chosen from a well-mapped space, rather than a laboriously devised construction’. Every esolang is a ‘laboriously devised construction’, in contrast to Landin’s best intentions. Chatley et al. (Chatley et al., 2019) envision the ‘next 7000 programming languages’ and discuss the reasons for language longevity. Esolangs exhibit none of the features required for longevity, albeit many of them are long-lived. Mashey explores why programing languages ‘succeed’ (Mashey, 2004). However again, the reasons do not seem to be applicable to esolangs in general. In the Onward! venue, there has been much discussion over the years regarding the nature of programming languages (Orchard, 2011; Noble and Biddle, 2023) with similar discussion at HOPL (Shaw, 2022). Steele and Gabriel (Steele and Gabriel, 2008) present 50 languages in 50 minutes: this live performance has taken place at a number of conference venues over the past few years. Their selection of languages include a number of esolangs such as Shakespeare (Computational Drama), Befunge (Stack Machines), and Piet (Visual Languages). It is striking that Steele, a seasoned and successful mainstream language designer, finds esolangs to be worthy of attention. McIver (McIver and Conway, 1996) lists seven design failures that would impair the efficacy of novice programming languages. Esolangs commit all seven ‘deadly sins’, from syntactic complexity to expectation violation. Mateas and Montford (Mateas and Montfort, 2005) discuss the sociological and phenomenological issues around esolangs. They link this community with the International Obfuscated C Code Contest (IOCCC), which is a celebration of unconventional code expressed in a mainstream programming language (i.e. C) but where the syntax and semantics of the language are highly abused in order to generate code that looks unusual (some kind of ASCII art, generally) and does something unexpected when compiled (some kind of textual output, normally). Cox (Cox and McLean, 2012) explores various non-technical aspects of esolangs in further depth. Temkin (Temkin, 2017) gives the most complete review of the esolang culture and philosophy. He seeks to explore the nature of esolangs, and the motivation for their design and use. His findings broadly concur with ours. His more recent study (Temkin, 2023) posits that esolangs enable ‘personal expression and …elegance within chaos’ and that they ‘challenge base assumptions of who languages are designed for and how they should be used’. Esolangs favour individual personality over practicality, and expression over comprehension. More generally, inspired by Gordon’s work relating programming languages to linguistics (Gordon, 2024), we see strong linkage between esolangs and the constructed languages evident in modern language study—from Elvish to Esperanto (Lo Bianco, 2004). ## 9. Conclusion Esoteric languages are, by their very nature, less accessible than mainstream programming languages. This goes against the prevailing trend, in terms of improving the accessibility of computing—whether from a usability or diversity perspective. So esolangs are implicitly contrarian, set against the direction of mainstream philosophy and advocacy. As we have looked at esolangs, we have endeavoured to learn something about the essence of programming, but in fact, we appear to have uncovered something about the essence of programmers… Precisely what? That they are a strange bunch? It appears that esolang users and developers derive perverse pleasure from the constraints and complexities of esolangs, engaging in the ‘technomasochism’ identified by Bratishenko (Bratishenko, 2009). Perhaps this observation does not apply to all esolang programmers, but certainly it covers a significant fraction. Ultimately, the use and development of esolangs is a form of freedom of expression (Cox and McLean, 2012). Such freedom must be preserved and valued by the community. Even if that freedom of expression allows people to express themselves in highly limited ways, the freedom to be so constrained must still be preserved. The key point of esolangs is that they enable exploration and experimentation in a manner that permits a ‘break from the bland, bloated multiparadigm languages with imperative roots’ (Kneusel, 2022). Esolangs challenge critical thinking ability regarding both programming language design and the nature of programming. Finally, a restatement of Perlis’ epigram is appropriate (Perlis, 1982): Epigram 19: A language that doesn’t affect the way you think about programming, is not worth knowing. For this reason above all others, esolangs are clearly ‘worth knowing’. Acknowledgements. We would like to thank the following people who gave us useful additional comments which improved this paper: Alan Blackwell, Norman Gray, and John Levine. This work was supported in part by UKRI/EPSRC under grant Sponsor EPSRC https://epsrc.ukri.org Grant #M4Secure. ## References - (1) - Abelson and Sussman (1996) Harold Abelson and Gerald Jay Sussman. 1996. Structure and interpretation of computer programs. MIT Press. - Beckwith and Burnett (2004) L. Beckwith and M. Burnett. 2004. Gender: An Important Factor in End-User Programming Environments?. In 2004 IEEE Symposium on Visual Languages - Human Centric Computing. 107–114. doi: 10.1109/VLHCC.2004.28 - Black et al. (2013) Andrew P. Black, Kim B. Bruce, Michael Homer, James Noble, Amy Ruskin, and Richard Yannow. 2013. Seeking grace: a new object-oriented language for novices. In Proceeding of the 44th ACM Technical Symposium on Computer Science Education. 129–134. doi: 10.1145/2445196.2445240 - Blackwell and Collins (2005) Alan F Blackwell and Nick Collins. 2005. The Programming Language as a Musical Instrument.. In PPIG. 11. https://www.ppig.org/files/2005-PPIG-17th-blackwell.pdf. - Brady (2013) Edwin Brady. 2013. Idris, a general-purpose dependently typed programming language: Design and implementation. Journal of Functional Programming 23, 5 (2013), 552–593. doi: 10.1017/S095679681300018X - Bratishenko (2009) Lev Bratishenko. 2009. Technomasochism: Getting spanked by INTERCAL. Cabinet Magazine 36 (2009). https://www.cabinetmagazine.org/issues/36/bratishenko.php. - Brooks Jr (1995) Frederick P Brooks Jr. 1995. The mythical man-month (anniversary ed.). Addison-Wesley. - Campbell-Kelly (2012) Martin Campbell-Kelly. 2012. Alan Turing’s other universal machine. Commun. ACM 55, 7 (July 2012), 31–33. doi: 10.1145/2209249.2209277 - Chatley et al. (2019) Robert Chatley, Alastair Donaldson, and Alan Mycroft. 2019. The next 7000 programming languages. Computing and software science: State of the art and perspectives (2019), 250–282. doi: 10.1007/978-3-319-91908-9_1 - Conway (1987) John H Conway. 1987. Fractran: A simple universal programming language for arithmetic. In Open problems in Communication and Computation. Springer, 4–26. - Corbett (2023) Jon Corbett. 2023. Cree Coding. Available from https://pinnguaq.com/stories/cree-coding/. - Cox and McLean (2012) Geoff Cox and Alex McLean. 2012. Speaking Code: Coding as Aesthetic and Political Expression. MIT Press. doi: 10.7551/mitpress/8193.001.0001 - Denny et al. (2022) Paul Denny, Brett A. Becker, Nigel Bosch, James Prather, Brent Reeves, and Jacqueline Whalley. 2022. Novice Reflections During the Transition to a New Programming Language. In Proceedings of the 53rd ACM Technical Symposium on Computer Science Education - Volume 1. 948–954. doi: 10.1145/3478431.3499314 - Dijkstra (1968) Edsger W Dijkstra. 1968. Go to statement considered harmful. Commun. ACM 11, 3 (1968), 147–148. - Faivre (1994) Antoine Faivre. 1994. Access to Western esotericism. SUNY Press. - Favre (2005) J.-M. Favre. 2005. Languages evolve too! Changing the software time scale. In Eighth International Workshop on Principles of Software Evolution. 33–42. doi: 10.1109/IWPSE.2005.22 - Gobbo et al. (2005) Federico Gobbo et al. 2005. The digital way to spread conlangs. Language at Work: Language Learning, Discourse, and Translation Studies in Internet (2005), 45–53. - Gordon (2024) Colin S. Gordon. 2024. The Linguistics of Programming. 162–182. doi: 10.1145/3689492.3689806 - Hall et al. (2008) Tracy Hall, Helen Sharp, Sarah Beecham, Nathan Baddoo, and Hugh Robinson. 2008. What Do We Know about Developer Motivation? IEEE Software 25, 4 (2008), 92–94. doi: 10.1109/MS.2008.105 - Hermans (2020) Felienne Hermans. 2020. Hedy: A Gradual Language for Programming Education. In Proceedings of the 2020 ACM Conference on International Computing Education Research. 259–270. doi: 10.1145/3372782.3406262 - Hermans and Schlesinger (2024) Felienne Hermans and Ari Schlesinger. 2024. A Case for Feminism in Programming Language Design. In Proceedings of the 2024 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. 205–222. doi: 10.1145/3689492.3689809 - Hudak et al. (2007) Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler. 2007. A history of Haskell: being lazy with class. In Proceedings of the Third ACM SIGPLAN Conference on History of Programming Languages. 12–1–12–55. doi: 10.1145/1238844.1238856 - Jones and Bonsignour (2011) Capers Jones and Olivier Bonsignour. 2011. The Economics of Software Quality. Addison-Wesley Professional. - Kang and Shaw (2024) Eunsuk Kang and Mary Shaw. 2024. tl;dr: Chill, y’all: AI Will Not Devour SE. In Proceedings of the 2024 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. 303–315. doi: 10.1145/3689492.3689816 - Kell (2017) Stephen Kell. 2017. Some were meant for C: the endurance of an unmanageable language. In Proceedings of the 2017 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. 229–245. doi: 10.1145/3133850.3133867 - Kelleher (2008) Caitlin Kelleher. 2008. Using Storytelling to Introduce Girls to Computer Programming. In Beyond Barbie and Mortal Kombat: New Perspectives on Gender and Gaming. MIT Press. doi: 10.7551/mitpress/7477.003.0022 - Kneusel (2022) Ronald Kneusel. 2022. Strange Code: Esoteric Languages That Make Programming Fun Again. No Starch Press. - Knuth (1984) Donald Ervin Knuth. 1984. Literate programming. Comput. J. 27, 2 (1984), 97–111. - Knuth (2011) Donald E. Knuth. 2011. Chapter 7: TPK in INTERCAL. In Selected Papers on Fun and Games. Center for the Study of Language and Information, Stanford, California. - Kolb (2014) David A Kolb. 2014. Experiential learning: Experience as the source of learning and development. FT press. - Kölling (2024) Michael Kölling. 2024. Principles of Educational Programming Language Design. Informatics in Education-An International Journal 23, 4 (2024), 823–836. doi: 10.15388/infedu.2024.29 - Kuutila et al. (2024) Miikka Kuutila, Leevi Rantala, Junhao Li, Simo Hosio, and Mika Mäntylä. 2024. What Makes Programmers Laugh? Exploring the Submissions of the Subreddit r/ProgrammerHumor.. In Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. 371–381. doi: 10.1145/3674805.3686696 - Landin (1966) Peter J Landin. 1966. The next 700 programming languages. Commun. ACM 9, 3 (1966), 157–166. - Li et al. (2022) Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. 2022. Competition-level code generation with alphacode. Science 378, 6624 (2022), 1092–1097. doi: 10.1126/science.abq1158 - Liu et al. (2023) Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2023. Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation. Advances in Neural Information Processing Systems 36 (2023), 21558–21572. - Lo Bianco (2004) Joseph Lo Bianco. 2004. Invented languages and new worlds. English Today 20, 2 (2004), 8–18. doi: 10.1017/S0266078404002032 - Lonati et al. (2022) Violetta Lonati, Andrej Brodnik, Tim Bell, Andrew Paul Csizmadia, Liesbeth De Mol, Henry Hickman, Therese Keane, Claudio Mirolo, and Mattia Monga. 2022. What We Talk About When We Talk About Programs. In Proceedings of the 2022 Working Group Reports on Innovation and Technology in Computer Science Education. 117–164. doi: 10.1145/3571785.3574125 - Mashey (2004) John R. Mashey. 2004. Languages, Levels, Libraries, and Longevity: New programming languages are born every day. Why do some succeed and some fail? Queue 2, 9 (Dec. 2004), 32–38. doi: 10.1145/1039511.1039532 - Mateas and Montfort (2005) Michael Mateas and Nick Montfort. 2005. A Box, Darkly: Obfuscation, Weird Languages, and Code Aesthetics. In Proceedings of the 6th Digital Arts and Culture Conference (IT University of Copenhagen). 144–153. https://nickm.com/cis/a_box_darkly.pdf - McDirmid (2013) Sean McDirmid. 2013. Usable live programming. In Proceedings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. 53–62. doi: 10.1145/2509578.2509585 - McIver and Conway (1996) L. McIver and D. Conway. 1996. Seven deadly sins of introductory programming language design. In Proceedings 1996 International Conference Software Engineering: Education and Practice. 309–316. doi: 10.1109/SEEP.1996.534015 - Nather (1983) Ed Nather. 1983. The Story of Mel. Available from http://www.catb.org/jargon/html/story-of-mel.html. - Nelson (2006) Graham Nelson. 2006. Natural Language, Semantic Analysis And Interactive Fiction. 141–188. https://www.ifarchive.org/if-archive/books/IFTheoryBook.pdf. - Noble and Biddle (2023) James Noble and Robert Biddle. 2023. programmingLanguage as Language. In Proceedings of the 2023 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. 191–204. doi: 10.1145/3622758.3622885 - Orchard (2011) Dominic Orchard. 2011. The four Rs of programming language design. In Proceedings of the 10th SIGPLAN symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. 157–162. doi: 10.1145/2089131.2089138 - Papert (2002) Seymour Papert. 2002. Hard Fun. Available from http://www.papert.org/articles/HardFun.html. - Perlis (1982) Alan J. Perlis. 1982. Special Feature: Epigrams on programming. SIGPLAN Notices 17, 9 (Sept. 1982), 7–13. doi: 10.1145/947955.1083808 - Peyton Jones (2003) Simon Peyton Jones. 2003. Wearing the hair shirt: a retrospective on Haskell. (January 2003). https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ invited talk at POPL 2003. - Raymond (2000) Eric Raymond. 2000. Guest Editorial: World Domination. Linux Journal (Jan. 2000). https://www.linuxjournal.com/article/3676 - Raymond (1990) Eric S Raymond. 1990. INTERCAL. https://gitlab.com/esr/intercal. - Raymond (2010) Eric S Raymond. 2010. Risk, Verification, and the INTERCAL Reconstruction Massacree. http://esr.ibiblio.org/?p=2491. - Ritchie (1996) Dennis M. Ritchie. 1996. The development of the C programming language. In History of Programming Languages—II. 671–698. doi: 10.1145/234286.1057834 - Sammet and Hemmendinger (2003) Jean E. Sammet and David Hemmendinger. 2003. Programming languages. John Wiley and Sons Ltd., 1470–1475. - Shaw (2022) Mary Shaw. 2022. Myths and mythconceptions: what does it mean to be a programming language, anyhow? Proc. ACM Program. Lang. 4, HOPL, Article 234 (April 2022). doi: 10.1145/3480947 - Steele and Gabriel (2008) Guy Steele and Richard Gabriel. 2008. 50 in 50. http://lambda-the-ultimate.org/node/3101. - Steele (1999) Guy L Steele. 1999. Growing a language. Higher-order and symbolic computation 12, 3 (1999), 221–236. doi: 10.1023/A:1010085415024 - Stroustrup (1998) Bjarne Stroustrup. 1998. Generalizing Overloading for C++2000. https://www.stroustrup.com/whitespace98.pdf. - Swidan and Hermans (2023) Alaaeddin Swidan and Felienne Hermans. 2023. A Framework for the Localization of Programming Languages. In Proceedings of the 2023 ACM SIGPLAN International Symposium on SPLASH-E. 13–25. doi: 10.1145/3622780.3623645 - Syme (2020) Don Syme. 2020. The early history of F#. Proc. ACM Program. Lang. 4, HOPL, Article 75 (June 2020), 58 pages. doi: 10.1145/3386325 - Temkin (2009) Daniel Temkin. 2009. Velato. http://velato.net. - Temkin (2017) Daniel Temkin. 2017. Language without code: intentionally unusable, uncomputable, or conceptual programming languages. Journal of Science and Technology of the Arts 9, 3 (Sep. 2017), 83–91. doi: 10.7559/citarj.v9i3.432 - Temkin (2023) Daniel Temkin. 2023. The Less Humble Programmer. DHQ: Digital Humanities Quarterly 17, 2 (2023). - Temkin (2025) Daniel Temkin. 2025. Forty-Four Esolangs: The Art of Esoteric Code. MIT Press. (to appear). - Thuné and and (2009) Michael Thuné and Anna Eckerdal and. 2009. Variation theory applied to students’ conceptions of computer programming. European Journal of Engineering Education 34, 4 (2009), 339–347. doi: 10.1080/03043790902989374 - Tiwari et al. (2024) Deepika Tiwari, Tim Toady, Martin Monperrus, and Benoit Baudry. 2024. With Great Humor Comes Great Developer Engagement. In Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society. 1–11. doi: 10.1145/3639475.3640099 - Tshukudu and Cutts (2020) Ethel Tshukudu and Quintin Cutts. 2020. Understanding conceptual transfer for students learning new programming languages. In Proceedings of the 2020 ACM conference on international computing education research. 227–237. doi: 10.1145/3372782.3406270 - Twist et al. (2025) Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, and Detlef Nauck. 2025. LLMs Love Python: A Study of LLMs’ Bias for Programming Languages and Libraries. arXiv:2503.17181 [cs.SE] https://arxiv.org/abs/2503.17181 - Wang et al. (2024) Chaozheng Wang, Zongjie Li, Cuiyun Gao, Wenxuan Wang, Ting Peng, Hailiang Huang, Yuetang Deng, Shuai Wang, and Michael R. Lyu. 2024. Exploring Multi-Lingual Bias of Large Code Models in Code Generation. arXiv:2404.19368 [cs.SE] https://arxiv.org/abs/2404.19368 - Wing (2006) Jeannette M Wing. 2006. Computational thinking. Commun. ACM 49, 3 (2006), 33–35. doi: 10.1145/1118178.1118215 - Woods and Lyon (1973) Donald R. Woods and James M. Lyon. 1973. The INTERCAL Programming Language Reference Manual. https://3e8.org/pub/intercal.pdf. - Yuan et al. (2024) Yicong Yuan, Mingyang Su, and Xiu Li. 2024. What Makes People Say Thanks to AI. In Artificial Intelligence in HCI, Helmut Degen and Stavroula Ntoa (Eds.). Springer Nature Switzerland, Cham, 131–149. doi: 10.1007/978-3-031-60606-9_9