In his classic paper “The Humble Programmer” (1972), Edsgar W. Dijksta called for putting aside personal style and overt cleverness in the interest of creating clean, readable, functional code. As he put it:
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
This can be thought of as a sequel to his “A Case Against the GOTO Statement,” (1968) which helped standardize a structured programming style built around a sense of flow – this is the next step toward readable code. Personal expressiveness at the code level such as using arbitrary variable names or employing obscure hacks (whether just to show off, or in the service of efficiency) reduce readability. It’s not only a problem for other programmers who may have to understand the code later, but, as Dijsktra points out, even more so for the author of the code herself, who has to fully understand what’s happening as she writes it. When low-level, bit-shifting hacks really are appropriate (e.g. when algorithmic efficiency is mandatory), the current norm is to include comments to explain what is happening, which are simply compiled away. Even those proponents of more minimalist styles like Spartan code are doing so with clarity as an overwhelming objective.
However, clever hacks are still with us; it is exciting to discover twists of logic that make code do weird things. Take for instance the recent post on JSFuck, where one brilliant, demented programmer used a behavior of JavaScript generally considered useless – that it returns the word “Array” from Array.toString() – in order to recreate the alphabet, building from those letters – and thereby writing code without using any letters at all. The result is a brainfuck-like stream of punctuation which is still perfectly valid JavaScript runnable in any modern browser. If the feature is there, even the completely useless one, some programmer will find a perverse use for it, no matter how absurd it may be. [See also: the templating language of C++ is itself Turing-complete]
Practices like esolangs, obfuscated code, one-liners, and code golf are all Less Humble practices. They create spaces for play in code, where it’s okay to use weird hacks, write the unreadable, or stretch the boundaries of programming.
The approach of using secondary features of code (like Array.toString() above) is a common strategy in Obfuscated Code, a style of programming which is perhaps the most obvious counter to Dijkstra’s advice. To obfuscate is to make code opaque – to draw attention to it as a text, reducing the ability to see the algorithms behind it.
The best-known competition for Obfuscated code is the IOCCC (the International Obfuscated C Code Contest). Many entries there opt for a form of code pattern poetry, laid out to resemble shapes or images, often in conversation with what the code performs, such as this work:
Adrian Cables’s 2012 winning entry features a quick brown fox, pattern poetry style. This is an OCR program – a program designed to convert analog writing into digital text, itself built in a form which refers to the alphabet directly (the “quick brown fox…” sentence) and is itself an illustration of that sentence – referring to it both in analog and digital means, written in an unreadable style.
Others might appear as if they were written in other languages like Visual Basic or Java, yet still functioning as valid C. To do this, a Visual Basic command named one way to actually carry out much different instructions, remapped by preprocessor instructions.
Interestingly, the IOCCC rewards attention to detail that are familiar as Dijsktrian goals: stability, including handling unexpected input, working across compilers. Many of the familiar values of mainstream coding are still in effect, just carried out in a completely different aesthetic. In a sense, this work challenges Dijkstra’s pronouncements while still internalizing its values. It is a place for code that must be successful according to the same criteria, yet written in a way that explicitly breaks from the sentiments of clarity and humbleness he gives us to help make the work successful in the first place.
Nick Montfort’s “Obfuscated Code” (in the wonderful collection Software Studies) looks at the principles behind this work:
Obfuscated code demonstrates that there are other aesthetic principles at play besides those “classical” ones that have been most prominent in discussions of programming aesthetics by programmers and critics.
One of the aesthetic principles of Obfuscated Code that Montfort mentions is that of conciseness, which is further emphasized in two other Less Humble coding styles: One Liner programs (which Montfort offers some great examples of in his piece) and Code Golf, a set of challenges that reward the shortest program which completes a specific task. Code Golf challenges offer Oulipean-syle constraints (not using the letter “e” is perhaps too easy, but not using letters you’ve already used provides a substantial challenge). Code golf can involve obfuscated programming outright as a challenge, but more commonly techniques arising from obfuscated practice are used in order to solve code golf problems. [Stack Exchange has an active Code Golf forum]
Where code golf and obfuscated code willingly embrace esoteric methods of programming, we can also see in these alternate methods a breaking away from the safety of high-level languages, a call back to what programming was like in the days of machine code – particularly in esolangs themselves.
Wendy Hui Kyong Chun has written about how giving up the direct interface with the machine was hard for early programmers. Chun quotes John Backus, developer of FORTRAN about the “black art” of early coding, saying they had a
“chauvinistic pride in their frontiersmanship and a corresponding conservatism, so many programmers of the 1950s began to regard themselves as members of a priesthood guarding skills and mysteries far too complex for ordinary mortals. Languages like FORTRAN opened up this world to people who were not trained in this black art.”
In a sense, alternative coding practices recreate this sense of code as an esoteric knowledge. Here not in a chauvansitic way, but with a sense of excitement in breaking new ground within deliberately obscure rules offered by an esolang or a set of code golf constraints. Each esolang creating a unique means of communicating with the computer that make sense only to esoprogrammers willing to bypass the niceties of mainstream computing. Esolangs may convolute code but do it in a way that gives esolangers access to low-level activity masked in the name of safety and ease provided by these high level languages. As crazy as brainfuck looks, it forces one to deal with memory cells directly; much of the delight of the language is in this engagement with the machine which is obscured by the safety of high level code and the “humble” approach of reducing complexity. The most extreme of which is probably Checkout, a language proposal that tries to give direct chip access to the programmer.
This opaque code – whether in the form of obfuscated work or esolangs – is also an exploration of code and language design as mediums in themselves, as much as deliberately using tape hiss or jpeg compression in visual studies of those media.