The Zero-Byte File
In his paper No Code: Null Programs, Nick Montfort looks at how the empty text file functions as code (and asks whether the lack of code can itself be a program). This is considered in light of uninscribed or erased works in other media: Rauschenberg’s Erased DeKooning drawing, Nam Jun Paik’s endless loop of clear 16mm film leader, Zen For Film, and most famously, John Cage's 4'33". Those works have none of what we ordinarily consider content for their respective media (drawing, film, or musical performance), yet in their refusal, none is truly silent: in Zen For Film, the scratches and dust on the leader become prominent, as do background and room noise in Cage’s “silent” work.
When we decide to compile/interpret an empty file as various languages (a C program, a JavaScript program, etc), we find that some languages consider the empty file valid code, others reject it, and in many the resulting behavior is undocumented, differing across compilers or operating systems. The null program in C is, in some systems, compilable. It was presented as a quine at the International Obfuscated C Contest in 1994, where it won for “worst abuse of the rules.” A quine prints its own source code: this null quine printed nothing, which is its own code. It was then disqualified for all subsequent years.
Montfort also looks at compiled code of zero size, with the zerobytes demo. Demos are prized for packing audiovisual effects in tiny code files – the smallest, zerobytes.com, creates this perfectly valid audiovisual effect, which is not a bad accomplishment for something that barely exists:
The Non-Performative Program
Zero byte files can be valid when read as text, but not so in some other formats – the reason the zerobytes.com file fails is because it is an executable without an entry point. Likewise, a properly constructed “contentless” gif, as he points out, opens with six bytes of header to mark it as that particular medium. For the gif, this might raise concerns about content vs structure (is that header properly “content”?). Here we give up the purity of the blank text file.
This content vs structure question come up on esolangs.org itself, where there was discussion over whether an otherwise empty program, with just an entry point might still be considered null, or if the blankness of the textual program is itself essential. This minimal C program is similar to the gif which has a header but no data:
main() {}
We can think of this is a Non-Performative Program: one that is valid within the language, but provokes no actions to be carried out. (using “performative” in the J.L.Austin sense of a text that causes things to happen in the world, er, computer). We might also think of this in terms of the code being a blank text (the empty file) vs a score for a blank performance (our minimal C program). This was a question dealt with by Cage as 4′33″ developed: the 1952 score (excerpted at the top of this post) used more conventional music notation, but as the work matured, was eventually replaced with the more well-known textual score (TACET I, TACET II, etc).
In esolangs, creating a non-performative program can be a weird experience, involving a non-trivial program file. The tension is no longer between the textual instructions and its performance (as with the null program), but between the concrete syntax (the actual text of the code) and the abstract syntax of instructions behind it.
Malbolge, the wicked language of self-modulating code (created by Ben Olmstead, interviewed previously) is similar to a number of other esolangs in that it needs a single, seemingly random character to create the non-performative program. We simply need the END instruction (without it, the program refuses to quit). It happens to be a capital Q (perhaps think of it as the quit command!):
Q
Although my first attempt at this program resulted in a segmentation fault, this is an easy Malbolge program to figure out by hand – as almost no other functional Malbolge programs are. Feel free to experiment with the language here. If we wanted to do a more sophisticated non-performative program, we could create an ever-increasing string of NOPs leading up to the END. Here are the first few:
DP
DCO
DBCN
In Piet, white blocks are ignored; so a GIF of all white pixels (a blank canvas!) is non-performative. An all-black GIF would likely work as well, although less efficiently, as the program would first look in several directions for color blocks that would give it a way to move forward (black pixels are blocking elements in the language).
Likewise, my language Light Pattern uses photographs, so giving it an empty file is not valid. An empty program (video can be seen here) can be made up of any photographic content that follows the correct pattern to create at least a single NOP. The example uses the most minimal content possible: photographs of pure red, green, or blue pixels at the exposures needed for a NOP to manifest. It actually uses the maximum number of these photos possible to create a very long string of NOPs (which get compiled away), until the exposures get too dark in the sequence to continue (all black).
Also, I realize I bring up this language all the time, but have to mention Unnecessary (previously discussed here among other places, created by Keymaker, interviewed here). There, a null program (empty file) is just as invalid as any other program file. The only valid Unnecessary program is actually smaller than a zero byte file: a file that does not exist on the file system. In a sense, every machine thus has an infinite number of Unnecessary programs.
***
Montfort’s paper can be found here.
Also of interest: the old Cats Eye page (by Chris Pressey, interviewed previously), listed the basic features of blank files: they are self-describing (the null quine), belong simultaneously to many languages at once (polyglots).
