It is with great excitement that we share the original INTERCAL-72 compiler source code, as both scans and transcriptions (see below). INTERCAL was created by Don Woods (previously interviewed here) and Jim Lyon as undergrads at Princeton in an infamous late-night session after freshman finals in 1972. Don recently rediscovered a print-out, on green-barred, continuous-feed pages, of the SPITBOL source code for the original compiler. If the legend holds true, this code had not been run since Woods and Lyon's Princeton days. Sean Haas (of the Advent of Computing podcast) and I transcribed the code from these scans, proof-reading each others' interpretations of fading characters. Haas has also produced a refined, runnable version of the script.

INTERCAL ("Compiler Language with No Pronounceable Acronym") is the first language that can unequivocally be called an esolang. While previous languages had odd designs as pl research and experimentation, INTERCAL intentionally subverts its programmers' effort to write what Dijkstra called "good code": that which "shortens the conceptual gap between the static program and the dynamic process." In INTERCAL, code is circuitous, full of symbols used in bizarre ways and with unique designations (#, for example, is the "mesh" sign). It is a challenge to read or to run in ones head, even for those deeply immersed in the language. Furthermore, it does this for parody and play, not with any practical aim in mind.

The length of INTERCAL's shadow cannot be overstated. It was twenty years after its creation that a series of minimalist languages (FALSE, Befunge, brainfuck) took the next steps toward what would become the esolang movement. INTERCAL-72 offered somewhat of a different path from these; it was less concerned with minimalism, and more explicitly dramatized the act of programming. Woods and Lyon described it as eschewing conventions of languages like ALGOL, SNOBOL, FOCAL, and AP/I, yet it is also clearly parody, embracing and exaggerating their worst eccentricities and inefficiencies for an alienating experience.

INTERCAL's most striking feature is its humanizing of the interpreter, a mercurial being who we literally plead with to get our programs to run. Use the command PLEASE too little and the interpreter will be offended and ignore the whole program; use it too much and it writes you off as a suck-up and... also ignore the whole program. Its subjectivity feels particularly relevant in an age when AI systems are designed to deliberately confuse the human and algorithmic. The influence of just this one feature can be seen in early parody languages like Chicken and Ook! that undermine the seriousness of the interpreter, to English, where the interpreter was once literally another person but is now downgraded to an AI prompt system. More personally, the interpreter for my language Olympus has many, competing personalities in the form of the Greek gods, any of which might become offended and ignore the rest of the program, in INTERCAL style.

However, for such an influential esolang, it is one that we experience primarily in derivative forms. The most well-known INTERCAL keyword (apart from PLEASE) is not part of the INTERCAL-72 language at all. That would be the COME FROM statement, an inverse of GOTO, where one has to trace back jumps from destination to source, like cheating in a choose-your-own-adventure book. It was added in 1990 by Eric S Raymond (interviewed here) for his adaptation C-INTERCAL. The original INTERCAL-72 compiler never left Princeton according to Woods; it is likely that ESR worked from the INTERCAL-72 manual without access to the reference compiler. Almost all who have used the language since then have actually used C-INTERCAL or one of its successors (CLC-INTERCAL etc). These later versions capture much of the spirit of the original but differ significantly in style and content. Now, with access to the original, we can experience INTERCAL-72 first-hand and make new discoveries.

Sean Haas describes the process of getting the ical.sbl (INTERCAL compiler) program running on a modern system, using SPITBOLx64. As he points out, ICAL is actually a transpiler; some of its infamous slowness is due to the overhead of generating a SPITBOL program and executing it. More surprisingly, it avoids SPITBOL's math functions, performing math through pure string manipulation. Sean discusses this in the latest episode of his podcast, Advent of Code, explaining the infamous thirty seconds needed to perform a single division:

The two operations you get, called MINGLE and SELECT, operate on binary data. Internally, ICAL will store numbers as a string of binary digits. A 4 becomes "100", for instance. When you operate on that number it's done as a string operation. The result is that any operation with numbers become this convoluted mess, both in INTERCAL and in the final output SPITBOL. Hence, 30 second divides.

The full set of scans and transcribed code can be found on GitHub.