The Hacker's Wheel - Programming as an Aesthetic Experience
Perl is often considered ugly, and a LISP program may not always be the Mona Lisa, but in the right programmer's hands, programming is still an aesthetic experience...
A question of Philosophy
The attraction of philosophy lies in its capacity to make the seemingly obvious appear in a new light.
For instance, to say that we are all thoughts in the mind of a virtual transcendent entity hides an extremely complex philosophical artifice. Thus, philosophical minds at their best are often able to reduce complex questions to their seemingly irreducible essentials.
The only sciences where similar questions and somewhat old-fashioned answers have occasional relevance are some sections of zoology, linguistics and astronomy. Zoologists have been trying to explain animal development since Anaximenes theorized about evolution during the early 5th century BC. The Indian linguist Panini developed a science of phonetics around 300 BC whose results astounded academics during the early 20th century. And various perturbation theories that explained the origins of planetary systems have been rediscovered time and again since the mid-18th century.
Ugly Perl Aesthetics
Clean, simple and deep philosophical answers do not tell us, however, why, e.g. Perl programs and the Perl programming language were often considered ugly, ie. why they were subjected to questions of aesthetics at all. I believe this question to have an increasing relevance in an age where the renaissance of programming languages has led to greater programmer choice and the growth of open source and programmer initiatives.
Knitting Is an Art, Aesthetics is a Science
We have to distinguish two objects of aesthetics that, in practice, build on each other: programming languages and programs.
As objects of a science of aesthetics, they are completely different: indeed, programming languages are by no means subject to the same aesthetic criteria as human languages - if languages should be considered as the objects of aesthetics at all - since they have no spoken referent. Neither do they permit that their rules are going to be broken, since their primary "interpreters", namely compilers, interpreters (in the computer science meaning of the word), and microprocessors, have very narrow rules as to how and when those rules, if at all, can be broken.
In the case of human languages, it is our minds and brains, regardless of whether human minds and brains are distinguishable from each other, that play the role of compilers, interpreters and microprocessors. Rules can be broken fairly easily and the more experience we have with human speakers breaking the rules of language, the more likely we are to make an accurate guess as to the meaning of ungrammatical, or indeed heavily distorted, utterances.
Of course, human minds/brains do much more than parse and transpose visual and auditory information into something ganglions can process. But our "virtual reality software" that seems to be part of our minds/brains is badly understood to this day, since it seems to process information coming through several channels and indeed it seems to be able to output concepts and images in weird and wonderful ways.
Do not Read the Program Aloud
Programs are slightly different. They do not have a spoken equivalent, although that is a point we will come to in a minute. They are composed of the elements of a programming language and, if we want to be utterly precise about it, code comments. We need to be slightly more careful about including code comments since they fall into the category of metalinguistics: they talk about programs or program segments and thus are not part of the program in its functional or aesthetic sense.
Code Needs Comments
One could argue, of course, that programs cannot be regarded as aesthetic objects as long as there isn't a mind or an environment within which the program can be regarded as "beautiful" or "ugly". Indeed, aesthetic judgments could form part of the code commentary, regardless whether code comments are present in the code or in a different medium. Code comments are, however, not part of the environment; They are a result of reflection, explanatory, aesthetic or otherwise that can form an outcome, but not part of, the process of aesthetic judgment.
I am aware that there are programming languages whose vocabulary can be extended and indeed be replaced, but since we are talking about programming languages and programs as an object of aesthetics, we will ignore this case for the moment.
Programs use the rules of a very restrictive recursive grammar to create complex sequences of instructions. They are sometimes known as algorithms, sometimes known as methods and members of classes, to denote the way in which what can be formalized as a Turing machine has to go about its short electronic life. Since we have included recursion, we can make allowances for the fact that programs will exhibit and use memory. If we added evolutionary characteristics, we could add constraints to the text of the program that would favour criteria of an an as-yet undefined notion of program "beauty", even though that does not seem to have happened.
We don't need no Stinking Humans
How does this make a program an object of aesthetics? We have to go back to programming languages. A programming language has something in common with written languages: it uses character sets, spaces and diacritic signs and sometimes layout conventions that can be seen to create a visible construct of some kind that can be read and understood by machines as well as human minds.
Human languages can be read and understood by machines, even though we have not succeeded in teaching enough of any language to a machine to consider it completely competent in speaking.
This is not an argument about artificial intelligence where we have to argue about the extent to which a computer has to learn a human language before we can consider the machine fully able to engage in dinner conversation: the point is that a computer can understand anything at all. And a computer can definitely "understand" and read a text, letter, by letter, and it can accurately reproduce it. In fact, homo sapiens finds it quite difficult to do the same thing to the same degree of accuracy.
Plus, a computer can understand strictly definied subsets of a human language, as long as the subset has clear boundaries and is very well structured.
Written human language is subject to aesthetic judgments: calligraphers and font creators can attest to that. We can, however, make it abundantly clear that we are not talking about aesthetic judgments on this level: we know that programmers and in many cases, readers of any kind of writing on paper or online do not especially care about the beauty of the individual letters.
Programming Language Ugliness
We do know, though, that programming languages, ie. their individual words, their syntactical rules and even their layout arrangements - I am referring to egregious cases like Py_thon and Cobol - are definitely subject to aesthetic judgment. For instance, it is considered ugly to juxtapose sigils like "$" and "&" with full words too many times. It is also considered unpleasant by many to use punctuation signs as parts of a programming language extensively, a practice harking back to the days of ASCII, when it was difficult to add new commands to existing Unix shells. Economy was important and adding new words to represent binaries that were run from the commandline was becoming difficult.
For historical reasons, programming languages like Perl and FORTRAN were able to pack an enormous amount of information into a single line, while making most people's eyes hurt. They lacked visual clarity. It was not possible to comprehend from a single look what they were doing and how they were doing it: indeed, parsing Perl code is about as easy as reading Homeric hymns in the original Greek.
This is a very important difference to human languages: typefaces and fontfamilies can vary heavily, but they refer to the sounds of the language, the combination of which usually in turn refer to the meaning. It is the sound and rhythm of the language that contributes towards the aesthetic impression, not their visual appearance. Of course there are written forms of language where visual appearance is extremely important: Chinese and Japanese poetry indeed rely on their visual appearance to add to the effect of the poem. But all poetry starts with rhythm or rather, its meter. The very notion of a sound of a programming language does not really matter to the perception of it. It defininitely does not add to its aesthetic perception.
There is a further grouping that we might want to take into account: object-oriented, functional and procedural languages are not really consistent as to their visual appearance. Although we have established that it is only their visual appearance that matters to aesthetics of programming, it is not the fact that the language follows the functional paradigm which contributes to its visual representation very much, jokes about parentheses in Scheme and LISP notwithstanding.
Although the programming language paradigm is undoubtedly important to the programmer's perception of the problem domain the language is supposed to be applied to, it is not the programmer's aesthetic perception that is likely to be affected by the programming paradigm: in other words, the extent to which the programming language is a result of a problem solving strategy seems orthogonal to its aesthetic appeal.
It seems that we are at sea. How come we regard programming as a source of aesthetic pleasure, yet we cannot find an overlap between the way in which it solves problems and and at the same time gives rise to aesthetic satisfaction?
Programming is An Art
The reason, I believe, lies in this: if we regard programming languages as algorithms (and despite appearances, they are little more than Turing-complete meta-languages to describe more specific algorithms), we are limiting ourselves in our appeal to an analytical approach to problem solving: it is as if a mythical race of beings on a distant planet had discovered programming as a means of understanding problems, without realizing they can do much more with it: using parts or composites of their language, they can also build constructs that have absolutely nothing to do with the problem solving capacity and analytical ability they set out to augment their minds with; their languages would be much more than tools to extend their minds: they provide the means for master craftsmen to become artists and build new worlds.
But I have to warn anyone to take this promise as a reason to see the promised solution of the problem of aesthetic appeal in programming languages as solved: indeed, what I said just now applies to programs (as the constructs we build), not to programming languages. Neither does it explain why some programs are being regarded as beautiful.
I must warn the non-philosophers among our readers to assume that the aesthetic appeal has much to do with the feeling of success a programmer tends to have when a program does its work particularly efficiently: it is a sad fact of engineering life that efficient solutions are rarely beautiful or elegant to look at. This is not to say that certain programming problems cannot be solved by programs that look good in some way on the screen. But the tools which they use are derived from the programming language they use and that limits the armoury programmers are permitted to deploy.
But there is slightly more going on.
LISP and the Mona Lisa
There is little doubt that programming in most of its manifestations is considered a creative activity: something is being written, that, protestations as to there being one optimal way of solving a problem in a given programming language notwithstanding, does represent a creative intent.
To say that a program represents a symbolic image of the state of a problem domain, i.e. part of the world itself, is not entirely relevant here: a program is meant to be (qua being) a tool used by humans to talk to machines. Sometimes, a program is meant to talk about a specific problem; a LISP program would certainly suffice in showing this. But this is a little bit like saying that the Mona Lisa makes an excellent cover for a wet patch on the wall. Yes, we can see it as a tool, and no, it wouldn't really convey any of its aesthetic or even artistic appeal.
There have been attempts at equating, for instance, Perl programs with poetry, but in essence they represent nothing but mechanical translations of Perl code into straightforward poetry: these programs represent exercises in technical ingenuity, and perhaps can be regarded as art, but it is unlikely that there very many people who would regard perl poems as objects of aesthetic experience. This is despite the fact that the results of their operation are definitely objects of aesthetic judgment.
What we talk about here is slightly different: many programs can be regarded as a lot more than tools to generate actions or even artistic results: they can be regarded as objects of artistic appreciation in the same sense that a painting (and not necessarily a painting manual or a brush) or a music piece (and not necessarily the score or even the instruments) can be regarded as objects of aesthetics.
Indeed, it is possible to regard the brush or the musical score as an object of aesthetic appreciation. Again, we should probably distinguish between the brush - we would prefer the mouse or the keyboard - and the musical score - we might prefer pseudocode, dataflow diagrams and the like - to make our discussions more precise. But those analogies would probably obscure our point rather than throw light on it.
Aesthetics and Programming Language Specs
If we exclude code comments and conditions framing the compilation process, and if we look at programming code somewhat more closely, we can detect a number of visual patterns: as has been pointed out by Geoff Cox, Adrian Lean and Jeff Ward, visual patterning is almost mandatory to make code readable. It is not enough to follow formatting rules imposed by (most) programming languages; the visual structure of programming blocks is almost as important as overall layout instructions without which it would be difficult for the compiler to see where code starts and ends. If, while, and for statements are classic cases. I would add consistent variable and function names that follow basic phonetic rules to make them distinguishable from line noise.
Then there are spacing and layout rules that are part of the programming language. They serve to space out and lay out programs in such a way as to avoid overwhelming the reader with information. They begin and end programming blocks, serving an aesthetic as well as a technical purpose. Further, it is often possible to look at code within several contexts in its various stages of execution, although I would not regard this point as decisive: looking at binary code or assembly language translation tends to obscure the point that code is meant to be a visual aesthetic experience.
Poetry is like code, Only....
It is sometimes said that poetry, just like code, can only be part of an aesthetic experience in execution and only then the poetry will gain meaning.
This is actually besides the point since nobody doubts that the meaning of anything, including code and poetry, is dependent on context. Aesthetics is by no means coextensive with semantics, though, since completely meaningless environments, like Martian landscapes, can provide aesthetic experiences, while quite happily existing without or within any previous linguistic framework.
This is somewhat simplistic, since reading aloud or reciting poetry is no way analogous to the execution of code: the visual poetic experience is mostly secondary - even in classical Chinese poetry - while in the case of code, the visual experience of code is primary to its aesthetic quality. There is also the central experience of any coder, namely an experience that rather is often rather inadequately called "an elegant solution" - which does NOT equate to a cool hack, I hasten to add.
The context of an elegant solution has a lot to do with a large repository of solutions and fragments thereof, plus a number of templates and patterns mostly present in the mind of the programmer, not in a computer and not in the program's execution context: indeed, I doubt very much that it has anything to do with the bits and bytes and architectures the code is being translated into and it is being executed in. Indeed, if one looks at the latest fashion in popular computer science, the worship of LISP according to its high priest Paul Graham, nothing could be further from his mind than execution contexts. What is very much on his mind is elegance and coherence, the way in which code communicates to its creators and readers, while not offending his or her aesthetic sensibilities.
What is the programmer trying to say?
Now, of course, we cannot avoid the question: what is code actually communicating? If aesthetic forms mold the code content, what is the code trying to communicate? Let us go back to the historical origins of code: it started life not as binary code in the modern sense, since binary code and hexadecimal numbers were the only code available: the code was the only language we could use to talk to a computer and as such was completely dominated by the demands of the machine: LISP started life as a mathematical notation that tried to add recursion to traditional logical notation.
Logicians at the root of Art
So, as a symbolic language, LISP tried to add functions and non-mechanical decision procedures to the very concepts of mathematical logic: its ontoloy was purely mathematical. The properties that can be added to mathematical notations are manifold and depend on the abstract structures and objects they are trying to describe: in many ways geometry was the classic example of a mathematical structure that could be visualized.
Clearly, LISP notation and the theory of computation harks back to mathematical logic and various algebras for inspiration. There is no doubt that algebra is not usually considered the object of aesthetic appreciation. LISP can be related to algegraic notations quite easily, (s-expressions are actually at the root of LISP) just as regular expressions can be regarded as a declarative language without functions or explicit conditionals with clear roots in abstract algebra.
Code as Pleasure
The point is this: the visual experience of code serves to heighten the aesthetic experience of abstract structures denoted by programming languages. This is where the pleasure lies, even though aesthetic experience is not normally associated with abstract structures. A close analogy is the experience of symmetry: even though we can go to a Renaissance building and marvel at the way in which the building has been built to express the order and peace of an (imagined) eternal universe, its very balance or symmetry shows the validity of geometric structures which are considered aesthetically pleasing by many.
Of course the building can be regarded as an example of civil engineering, but its validity rests in its exemplification of (very rudimentary) projective geometry. As such, it serves to produce aesthetic pleasure in the mind of the viewer. The aesthetic pleasure is not related to its purpose.
Similarly, programs show the validity of abstract algebraic structures, and possibly, and more specifically, algorithms and as such, will be subject to aesthetic judgement. And that means that programs can be regarded as divorced from their execution process: they are experienced as instantiations of mathematical ideas; their implementations and symbolic representations become aesthetically valid.
Code and Aesthetics
Philosophy of mathematics
The History of Aesthetics
What is LISP?
Beauty in Mathematics