Computational idealism is a code aesthetic introduced midway through M. Beatrice Fazi's book Contingent Computation. She describes it as holding "the classical age's concern with the supremacy of simplicity over complexity, of order over chaos, and of unity over parts."

Fazi describes it as a mathematician's aesthetic ideal of harmony and simplicity that sits behind much of what is considered elegant or beautiful in computing.

[C]omputational idealism holds that an equivalence between beauty and truth can be found via logical proof: computational structures are truthful insofar as they are logically consistant; this consistency is beautiful because it adheres to the axiomatic character of computation.

This might sound like it has little to do with esolangs, which do not in particular favor order or simplicity, but is actually a very useful tool to understand classic esoteric coding practices. In fact, Fazi introduces this concept, not with a particularly clever sorting program or other classic algorithm, but with code associated more with mayhem and machine disobedience: Jaromil's Fork Bomb:

:(){ :|:& };:

This, the most-tattooed program of all time, has an alien, machinic character that might look like brainfuck or another esolang at first glance, but is pure vanilla shell script: type this into a Mac's terminal, hit enter, and the machine will freeze (please don't actually try this). In other words, it runs, as is, on a platform many of us already have.

A fork bomb is a program that reproduces itself endlessly. It does only one thing: it forks into two processes. Each of these then forks into two, expanding exponentially until all system resources are exhausted, the machine overwhelmed. Florian Cramer described them in a 2006 lecture as "a secret code of recognition among the initiated":

Forkbombs have been popular entertainment among hackers since about the mid-1990s, but Jaromil manages to condense them to a most terse, poetic syntax, arguably the most elegant forkbomb ever written.

Fazi goes even further in highlighting the elegance of this program, rather than its disruptiveness:

I will not be addressing the fork bomb here as a glitchy product of imperfect computation. This is because I am interested in viewing it in entirely the opposite manner. In other words, I am interested in pursuing the sense in which Jaromil's script is neither an anomaly nor a bug, but rather a small program that does exactly what it is supposed to do.

To better understand how the fork bomb participates in this mathematically-oriented, "axiomatic" style, we might first take a look at the aesthetic computational idealism describes.

 

Knuthian Elegance

Some programs are elegant, some are exquisite, some are sparkling. My claim is that it is possible to write grand programs, noble programs, truly magnificent ones!
- Knuth's preface for The Art of Computer Programming

The term "elegant" used by Cramer is highly associated with the dominant aesthetic of code, which Donald Knuth is perhaps the computer scientist most responsible for defining. While Fazi only passingly refers to Knuth, I argue that her computational idealism describes a distinctly Knuthian approach to code.

This is important because Knuth gives us an aesthetic of code, but not an aesthetic theory; his aim is to teach code craftsmanship, not to describe, let alone analyze, the history or assumptions supporting his approach. This we can get from Fazi. Knuth's view is expressed primarily in his ever-expanding, multivolume The Art of Computer Programming. Growing over forty-plus years, it has an abundance of algorithmic analysis, in books grouped in wide categories. Volume 4 and its updates have been written over 20 years, and volume 5 is estimated for 2025. The volumes I'm most excited about, 6 on CFGs and 7 on compilers, will be released following after, "God willing" (according to Knuth's TAOCP website).

Matthew Fuller describes Knuth's aesthetic in his essay Elegance (2006) collected in the classic book of essays Software Studies:

In Literate Programming, Donald Knuth suggests that the best programs can be said to possess the quality of elegance. Elegance is defined by four criteria: the leanness of the code; the clarity with which the problem is defined; spareness of use of resources such as time and processor cycles; and, implementation in the most suitable language on the most suitable system for its execution.

Is the fork bomb elegant (in the Knuthian sense) when considered within these criteria? Leanness is the central characteristic of the piece; as Fazi describes, "minimizing inscription whilst maximilizing functionality." The spareness of resources we can forgive because the very point of the program is to expend those resources as quickly as possible. The clarity of the problem is not in question: crashing a computer is a very clear problem that the program solves in a way that continues to work on most machines without installing any additional components 18 years later. Clarity of the code itself is not listed here, but we can excuse Jaromil's fork bomb for the moment from this clarity, as the expense of its extreme leanness—we will revisit this last point in the next section.

Knuth's The Art of Programming is not just a guide to well-written code. It is explicitly about the algorithm, which he situates at the center of computer science. In his preface, Knuth writes:

"Information processing" is too broad a designation for the material I am considering, and "programming techniques" is too narrow. Therefore I wish to propose analysis of algorithms as an appropriate name for the subject matter covered in these books.

Warren Sack, in his book The Software Arts, does not see this as an accident. While his entire argument is long to recount here (and will be taken up in another post), Sack connects the centrality of the algorithm with the emphasis on the mathematical aspects of computing. Think of the algorithm as what is runnable within the Turing Machine itself, so excluding things like I/O and interaction with other systems. As Sack states, "Only some software can be rendered as mathematics—the software that implements algorithms!" In other words, the centrality of the Turing Machine in computer science is what keeps comp sci (artificially) rooted in mathematics.

We can see more evidence of Knuth's sidelining of non-algorithmic thinking in his chapter "Input and Output", one of the few on interaction. It begins with a warning that "many computer users feel that input and output are not actually part of 'real' programming." Sack points out that practical programming involves a large amount of interaction and systems design. Most of us who are programmers with a day job deal with tedious tasks almost 100% of the time: interpreting old code, getting two systems to communicate, etc—and are not called on to consider algorithms beyond selecting one that feels appropriate.

This is all to say that Knuthian elegance is algorithmic elegance, and that this draws from the aesthetics of math, with its latent Platonism, emphasis on axiomatics, and "beauty in simplicity" that Fazi describes in her computational idealism.

Is the forkbomb primarily an algorithmic work? As Fazi describes it:

The pace of the fork bomb is relentless, inexorable, inescapable... Given the necessary conditions, it works independently of empirical phenomena and users. There is no evolution, no generation, no dynamism—only the internal repetition of its conditions of logical necessity.

As simple an algorithm as the forkbomb has (with "no evolution, no generation, no dynamism") that entirely defines the program—there is no interaction, no activity in the program apart from this simple repetition. Had it frozen the machine by, say, interfering with a device driver, or tricking the user into downloading something malicious, it might freeze the machine successfully, but lose this simplicity, and would no longer be self-contained; the aspect of "logical necessity" would no longer hold.

The fork bomb seduces and scares as a result of the effectiveness of its method, and because of the intrinsic correctness of its proof.

 

Esoprogramming as Re-asserting Computational Idealism

The fork bomb has been described as a "computational readymade" because of the simplicity of its design. I also excused its lack of clarity in the last section due to its extreme brevity. But imagine if we changed the name of the only function in the program so that the fork bomb read like this:

f(){ f|f& };f

Now it is much easier to understand. It declares a function, f(), which calls itself twice. Even if you're not familiar with the | and & symbols (& runs a process in the background), the logic of the program becomes clear. The semi-colon near the end separates the function definition from the final command: an initial call to f. That is the fuse that ignites the bomb.

This program is the equivalent of Jaromil's version in brevity and terseness, and just as single-minded in its execution: only a variable name, something irrelevant to its execution, differs. But no one will be getting a tattoo of this version.

The aesthetic of the fork bomb, in other words, is not entirely determined by necessity and brevity, but also involves the conscious choice to make the short program appear alien and inscrutable, written in all punctuation. It makes the script feel machinic, not at all intended for the human reader. Jaromil's fork bomb is perhaps the shortest program that one could call obfuscated.

Perhaps what makes the fork bomb so appealing an example of computational idealism is that it retains elegance even when written in conditions that normally would lead us to the opposite of elegance and in defiance of "good code craftsmanship". And here we get into how this elegance functions in esolangs.


Me presenting the forkbomb at Parsons Paris in 2014

The hacker aesthetic is often seen as an alternative to elegant code; it was described this way by me just a few weeks ago in this Hyperallergic article. But brainfuck is perhaps better characterized as a fusion of the elegant and the obfuscatory. Brainfuck is a subversive language in its design. It works against the Dijkstrian model of neutral-voiced, faux-objective programming, instead embracing explicitly arbitrary signs, chosen in defiance of readability. It is not designed for practical programming, rejecting clarity, modularity, and most common notions of good code design.

But brainfuck is not only a provocation; it is also a puzzle. Its creator, Urban Müller, had the objective to create a Turing Complete language with the shortest possible compiler. The objective is fully realized—not when Müller published the compiler—but through the hundreds of esoprogrammers who discovered algorithms for it. The brainfuck programmers here do not get to play the role of the subversive artist, they instead participate in making brainfuck work by writing elegant programs within its oddities, in an Oulipian dynamic.

Look at the example of brainfuck constants. The esolangs wiki is full of surprising and brilliant ways to get brainfuck constants, organized in a very practical way, by their length in characters, and the number of times they have to wrap past zero to get to their target values. Here are the algorithms to produce the number 46:

+++++[>+++++++++<-]>+ (21, 2) non-wrapping
--[>+<++++++]>+++ (17, 2) wrapping
>-[[---->]<<-]>- (16, 3) wrapping
+[-[--<]>>--]<- (15, 4) wrapping
-[+>+[+<]>+]> (13, 5) wrapping

They are each cleverly realized, and sorted by different types of efficiency: in speed, in size (number of characters), in limits. They are short, elegant pieces of code for a system designed to force the programmer to find elegance in challenging conditions. These esoprogrammers produced something new and different that in the end achieves familiar goals, reinforcing the underlying philosophy of simplicity and bareness—the Knuthian aesthetic—in code that falls far from its conventions.

It's like a cliché superhero film. We enjoy wreaking havoc with the villain in the middle of the film, but the story isn't complete until the hero reasserts order at the end, letting us have it both ways.

In the more interesting esolangs of this variety, which include not only brainfuck but many of the old-school Turing Tarpits, the premise is so far-fetched and bizarre that the reconstruction of order brings with it an intriguing challenge to programming.

The language Malbolge, designed to be the most difficult language to write in, was "beaten" by treating it as an encryption problem. Because of its extreme difficulty, it retains a sense of mystery around it, inspiring this oddity, yet it is now possible for algorithms in a meta-language of Malbolge to efficiency generate code for this seemingly least-elegant language. Malbolge delights in remaining a little out of reach.

Likewise, in obfuscated code, the apparent chaos of the work is justified by its secret order. Those that are most celebrated enact complex and clever algorithms by embracing computational idealism despite the code's appearance. Like Jaromil's fork bomb, elegance in obfuscation creates a conflict that's aesthetically compelling.

By expanding how we can talk about the dominant aesthetic of code, Fazi allows us to see the classical order in such programming practices that at first glance seems to fall very far from it. By drawing from Knuth (guided by Sack), we can recognize the mathematical justification behind this aesthetic, reinforced in computer science instruction. This grants a new set of tools to understand the play of esoprogrammers in the logical space. Esolangs that seem subversive may be countered by the re-emergence of computational idealism, lurking in pieces that seem to express the opposite. These systems delight in pitting the impulses of chaos and order against each other, either to create works that are intentionally unresolved but often, as in brainfuck, to ultimately allow computational idealism to emerge under the conditions that seem to defy it.