Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
The Less Humble Programmer
Summary
The Less Humble Programmer investigates the aesthetics of esolangs (esoteric programming languages) as drawing from / challenging / reacting to two competing aesthetic impulses in mainstream computing and computer science:
The first is, borrowing from Dijkstra, Humbleness. This is the neutral voice of code that downplays personal style. It values clarity above all else, including, for the most part, efficiency. This is code that is friendly to corporate coding, easily understood by others. It is how we, for the most part, are taught to code, even creative coders.
The second is conciseness and cleverness. This is the view of "elegance" drawn from mathematics, valuing of the shortest expression that says or does the most. It prizes conciseness and (sometimes) efficiency over clarity. It is familiar from other hacker arts (e.g. demoscene) and was commonplace in early computing when extreme efficiency was necessary.
In Wendy Chun's Sorcery and Source Codes, she discusses the move in mainstream coding from the second aesthetic to the first, when programming became professionalized and corporatized. But the impulse to show technical wizardry through clever and unreadable code never went away; it simply finds other avenues for expression.
An Esolang Example
Consider brainfuck, the language that infamously recreates the Turing machine offering only eight commands to the programmer, each represented by a punctuation mark. The + adds one to a memory cell. < and > let us navigate through memory cells. The square brackets loop until the memory cell pointed to is at zero.
Brainfuck has an absolute refusal of Humbleness; there is no neutral way to express anything in the language and there are no standards to adhere to. One must make a choice even for the most trivial of code.
If we want to print 46 to the screen, we could have 46 +s followed by . (the command to print):
++++++++++++++++++++++++++++++++++++++++++++++.
This is not especially readable, as it is too many +s to recognize at a glance.
Then there is the multiplication pattern: one cell starts with a value and counts down, each time adding a second value to the neighboring memory cell, effectively multiplying the first by the second via a loop of addition. It multiplies 5 by 9 and then adds 1:
+++++[>+++++++++<-]>+.
And here is the shortest (known) brainfuck algorithm to print 46:
-[+>+[+<]>+]>.
It is extremely short, has an appealing rhythm of +s and brackets, but is mostly unreadable without playing out a complex algorithm in ones head. It is a loop within a loop and gets to 46 by walking back and forth across six memory cells. It wraps past zero (in brainfuck, zero minus 1 is 255) many times. It is efficient in number of characters, but is the slowest in execution.
These alternate solutions show how brainfuck may appear chaotic, but it prizes the re-assertion of order within a seemingly chaotic space. It is chaos to be tamed. The most celebrated approach will be the shortest or the most efficient.
Questions
Esolangs have matured as a medium since 1993, when brainfuck appeared, and deal with a wider set of concerns. I've been thinking lately about how current esolangs build on these foundational aesthetics. The language Unnecessary (2005), for instance, refuses any form of computation: its only valid program is the one that doesn't exist. This is an example of the kind of idea art that allows no space for technical wizardry, by taking formal play with language design to its most extreme, yet feels indebted to the early esolangs in that choice. I wonder how other current esolangs engage (or do not engage) with these aesthetics of early esolangs.
Also, how is this thinking reflected in code poetry? Code poetry is one of the other code forms (along with esolangs and demos) where one has the freedom to break from clarity. At least some code poets, (such as the recent book ./code –– poetry, poke fun at the mathematical idealism of code -- in their case via the (much hated) golden spiral.
Comments
Unfortunately, I don't think I'm answering any of your questions, but they made me think of one situation I experienced regarding esolangs.
I don't have a deep knowledge of how to build programming languages; nonetheless, for some years, I have been interested in them as a way of expression. I conducted a small workshop with master students, and one of the tasks was to create a prototype or concept for a piece of 'aesthetic software', and some of them came up with very interesting concepts that couldn't be implemented because we lacked the technical skills (and the time... ).
What was interesting for me was how the idea of esolangs made them see programming languages from a new perspective, and how, of course, they were running away from the "neutral voice of code" you mentioned in your first aesthetic principle.
At the same time, the fact that they were concepts and the way they presented them, making use of visual support, somehow made it look close to some kind of 'code poetry' written by non-existing programming languages, if that makes any sense...
Thank you, I very much appreciate this thread. I agree that esolangs now derive from many wider concerns, as you write above -- many types of experiments encompassing many broad and overlapping categories, such as (some categories that I observe):
1) targeted tactical and parodic languages that attempt to subvert a dominant programming language in use today, or in use historically;
2) pseudolanguages productive of pastiche, or non executable code;
3) languages designed to provide an experimental playground to study issues of computability and complexity;
4) languages that attempt to push the boundaries of minimal code;
5) languages that are expressions of form, an expression of syntactic formalism (with little regard to compiler construction, more or less, or that piggyback on other languages; and
6) possible tools for analysis and evaluation (??).
The possibilities for rich, interdisciplinary avenues of research are reminiscent to me of the art and engineering collaborations of the 1960s and 1970s, such as those at Bell Labs and EAT (Experiments in Art and Technology).
Thanks for these thoughtful responses!
@martapcampos:
One great thing about esolangs is that their raw material is logic, not code. And that can lead to work like what @tdddkk describes as "pseudolanguages productive of pastiche, or non executable code." There are many experiments that willfully refuse computation or expand the idea of computation to something we can't code or can't run.
For instance, David Madore's hyperarithmatic machines: perfectly valid languages that can only run on infinitely large machines. With infinitely large machines, they can break fundamental rules of computation, including the Halting Problem. Whether this is truly an esolang or simply a piece of theoretical computer science is up for debate, but to me, it is both. Strictly speaking, one can write programs for it, but of course the nature of the universe prevents us from ever building a machine to run them.
A language can thus be complex technically and conceptually and lack implementation for many reasons. This is something that I rely on when I teach esolangs to a less-technical audience: they can dream up a language that may or may not be implementable, but that doesn't mean it can't be clearly defined.
I have a language in the works called Stroll, which is built on a meandering walk through the city. It relies on aspects of the city that can only be observed (and judged) by a person. The language has an unambiguous syntax and semantics, but there is no "implementation" as interpreter or compiler because the machine (at least currently) lacks both a body and the nuance necessary to identify features of the street integral to the language. This is not a technical shortcoming, as the language is designed as antagonistic to that technology -- but I am also not ruling out that it could become automated in the future when that technology changes.
@tdddkk: This list of categories is great. Just to fill out a few examples:
The language often considered the first (INTERCAL, created 1972) is clearly a parody langauge poking fun at the antagonism between person and machine. And recently we have had more languages that challenge dominant paradigms of code (such as, discussed in previous ccswg, قلب and Cree#, which both challenge the dominance of English in computing).
3 and 4. The Less Humble Programmer is mostly dealing with these two categories, as they make up much of easly esolangs. Minimalism was often the impetus or perhaps justification for creating oddball languages. FALSE and brainfuck (both 1993) were minimalist languages, which necessarily resulted in odd syntax.
Since then, some of the most celebrated esolangs posit bizarre virtual machines as experiment, often with no idea what computational complexity they have (what can be written in them).
Yes, and I think this is an especially interesting time for esolangs as more digital poets and artists approach the medium and make works in conversation with the hacker/hobbyist work that predates them.
@Temkin if possible, I would like to add to your questions another "form" (of code poetry? of non-humbleness?): the obfuscated code contests. There, one can surely find conciseness and cleverness and never clarity.
These three object (esolangs, poems and obfuscated codes) are my favourite arguments against the general idea of programs like implementation of algorithm to solve problems.
I suppose that there is a relationship between creating a clever and obscure language and using a clear language to get an obscure result. In a sense, one is the opposite of the other, but they share the same refuse to do humble things.
Poems lie in the middle?