The role of aesthetics in the understandings of source code

The rest of this conclusion will address each of our initial research questions' findings, followed by an examination of the limitations and contributions to existing research on source code. Throughout, we will summarize how our comparative approach highlighted medium-specific aesthetic devices whose function is to engage epistemically with their audience.

One of the gaps we identified in source code-related literature is that there was a missing overlap between a broad empirical approach and a robust conceptual framework, expliciting the nature of source's code properties. For instance the works of ( Paloque-Bergès, 2009 Cox, 2013 Black, 2002) establish an overview of source code with explicit aesthetic properties, but rely on a remediating approach to assess source code as a literary-semantic tool, or as a discursive-political object, respectively, all the while focusing on the subset of so-called creative code. We intended to complement this initial work by highlighting source-code-specific aesthetics—that is, formal manifestations with a communicative purpose, beyond a strictly literary perspective.

Starting from trade literature on the topic, and complementing it by cases of close-reading program-texts, we have highlighted both structural and contextual specificities of source code. Building on existing work across disciplines, such as Martin (see Crafting software ), Gabriel (see Patterns and structures ), Lakoff and Johnson (see Metaphors in computation ) or Détienne (see The psychology of programming ), we have found several properties which seem to be unique to source code, and supports a conception of source code as a material used to construct dynamic semantic spaces.

First, conceptual distance is key at a structural level: correlated expressions, statements or variables that affect or depend on the same concept (e.g. a file operation or a user account), should be located close to one another in the source code. This counterbalances the entropic tendency of source code to tangle itself, such that the reader has to follow the convoluted machine path of execution, rather than the human conceptual grouping of executable statements.

The conceptual coherence , and thus its ease of understandability, is also manifested in conceptual atomicity and conceptual symmetry, respectively meaning that a given explicit fragment of source code should only refer to one specific operation, at a given level of abstraction, and that fragments of source code that do similar things should look similar as well. Also previously identified as separation of concerns , these two principles allow for the abstraction of a given syntactic unit by grouping all the statements into a single action or declaration, thus operating as a bridge between human understanding and machine understanding.

At the lexical level, source code is multi-dimensional. On the one hand, it operates on an axis that goes from global to local , whereby global tokens that are used, and are visible, across the whole application code are very explicitly named, sometimes in all uppercase, while local tokens, whose lifetime does not exceed a few lines, tend to be composed of just a few letters. Here, variable length and cap size is closely related to the concept of scope , yet in a slightly looser way than from a strict programming language perspective. On the other hand, lexical tokens can belong to three different lexical fields. These lexical fields are whether a given token refers to (1) an individual meaning, (2) a machine meaning, or (3) a domain meaning. For instance, the names start_time , UTC_UNIX_STRING_NOW and meeting_time might all refer to the same moment in time, yet from different perspectives. The first naming, as an individual meaning, is significant in a narrow context, for a narrow set of individuals at the moment of writing or reading. The second naming is a machine meaning, which refers to how that moment is perceived by the computer. The third is the domain meaning, which is how end-users will refer to that particular moment. The use of a different names to refer to a single entity has also shown that metaphor theory comes into play.

For some, a piece of source code which can choose a token that will balance these three meanings in order to convey these three senses of the value at hand will be considered aesthetically pleasing. For others, writing tokens at the extreme of either of these three poles can be considered as a marker of aesthetic success, accompanied by a certain degree of expertise. For instance, code poets would tend to focus on the domain meaning, in which tokens are only referring to non-computing terms, and evoke poetic concepts instead. Conversely, hackers share a standard for brevity and directness—by making their tokens as short as possible, e.g. reducing them to bytecode, they strive towards existing as close as possible to the hardware that the code depends on, and therefore display unsual feats of performance.

As source code gets closer to the hardware, the representation of its semantics change. Aesthetics move away from surface and towards depth, and human-readable names disappear. So, while syntax such as names and comments might be beacons with an aesthetic potential, positively-valued structural arrangements subsist in a different form. One form of structure, such as the files and folders organization of some codebases, create a sense of familiarity in the situated programmer, as seen in Compression and habitability in functional structures . However, we can also note that structure can evoke less-human concepts, and be considered aesthetic insofar as they present a stimulating mental puzzle where the discovery of the program text's computational function is the ultimate reward, as discussed in Hackers . For instance, the program text presented in

0x31


mov    rcx,rax
shr      rcx,1
xor      rcx,rax

inc      rax

mov    rdx,rax
shr      rdx,1
xor      rdx,rax

xor      rdx,rcx

- This Assembly listing represents a pair of numbers as reflected binary numbers, and then performs a logical operation on a pair of numbers. The structure of the program text itself, through its symmetry, hints at the patterns exhibited by such reflected binary encoding . ( xorpd, 2014)

displays an aesthetic structure, independent from syntax. It seems at first very cryptic, but nonetheless exhibits a certain regularity and symmetry in its layout.

Published in xchg rax, rax , a collection of riddles in the Assembly language, this seemingly cryptic example allows us to show that, while no arbitrary names are used, structure nonetheless survives ( xorpd, 2014) . Borrowing from poetry's lexicon, we can identify four stanzas, twice of four lines, and twice of a single line. Syntactically, one can easily spot the repeating of a pattern, with a mirrored relationship between rcx and rdx , two of the CPU's memory registers where temporary information is stored. The first stanza raises a given number to the exponential of itself, bitshifted to the right ( x^(x>>1) ). The second increases the original number, the third stanza repeats the first operatio with the previous number and the last, concluding line calculates the xor result. The 3-1-3-1 repeating pattern and the similar registers being used across stanzas makes it such that, at first glance, its structure evokes the concept of reflection and symmetry.

0x31


mov    rcx,rax
shr      rcx,1
xor      rcx,rax

inc      rax

mov    rdx,rax
shr      rdx,1
xor      rdx,rax

xor      rdx,rcx

- This Assembly listing represents a pair of numbers as reflected binary numbers, and then performs a logical operation on a pair of numbers. The structure of the program text itself, through its symmetry, hints at the patterns exhibited by such reflected binary encoding . ( xorpd, 2014)

Semantically,

0x31


mov    rcx,rax
shr      rcx,1
xor      rcx,rax

inc      rax

mov    rdx,rax
shr      rdx,1
xor      rdx,rax

xor      rdx,rcx

- This Assembly listing represents a pair of numbers as reflected binary numbers, and then performs a logical operation on a pair of numbers. The structure of the program text itself, through its symmetry, hints at the patterns exhibited by such reflected binary encoding . ( xorpd, 2014)

tells another story. The semantics of this program text is to compute the exclusive OR of two consecutive reflected binary codes. The binary reflected code, also called Gray Code, is a way to represent binary numbers in such a way that incrementing from one number to another only changes one byte. Following this notation, incrementing from 1 to 2 would be written from 001 to 011 rather than from 001 to 010²²⁰ .

This kind of binary number representation relies on a linear increment which exhibits further structural properties. For instance, reflected binary numbers are used in electronic and digital communications, as well as signal processing, in order to reduce errors in information analysis (since only one bit changes from one binary number to the next, it becomes easier to trace through linear changes and catch mistakes). For instance, this particular snippet could be used to detect if there was an error in an encoding of information by acting as a test control: since it calculates the exclusive or of two consecutive numbers, there should only ever be a single 1 in the result, and any more or less flipped bits would indicate an error in the processing.

However, like the aesthetics of mathematics, we here start from this somewhat simple syntactical representation, followed by a changing of the scale at which it operates, in order to grasp a more complex, yet highly regular, structure. In fact, such a structure is used in puzzles like the Towers of Hanoi, or the Chinese rings puzzle, and is an example of combinatorial algorithms ( Knuth, 2011) , reconnecting the hacker aesthetic to a certain kind of playfulness. Through a poetry-like layout and with a mathematical intent at evoking complex numerical concept, a seemingly simple program text allows us, with a subset of source code aesthetics, to grasp a complex computational structure. Away from names and human idiosyncracies, aesthetics persist²²¹ .

The name Assembly, the language in which

0x31


mov    rcx,rax
shr      rcx,1
xor      rcx,rax

inc      rax

mov    rdx,rax
shr      rdx,1
xor      rdx,rax

xor      rdx,rcx

- This Assembly listing represents a pair of numbers as reflected binary numbers, and then performs a logical operation on a pair of numbers. The structure of the program text itself, through its symmetry, hints at the patterns exhibited by such reflected binary encoding . ( xorpd, 2014)

is written, also evokes hints of craft, and program texts in Assembly are often referred to as "hand-crafted". As we showed in Crafting software , with craft comes communities of practice. Such communities are also an influence on what is to be considered aesthetically pleasing code. With a strong ethos of craft running as a thread throughout each of these identified communities (see Aesthetic ideals in programming practices ), well-written code is idiomatic code . This implies that the reader and the writer both possess some knowledge of the specificities of the language or hardware that the code is being written with and executed with. While skilled work is often related to a positive appreciation of the result, craft also includes a conception of being usable.

This social existence of code and its connection to skilled work also led us to examine the role of style . Style, in this case, is valued positively when it represents the acknowledgment of the social existence of code: by choosing style as a group marker rather than as an individual marker, a source code is judged positively based on its altruistic ethical nature.

More fundamentally, the aesthetic properties of source code are derived from a conception of code as a semantic material which in terms is assembled, and apprehended, as a spatial construct, rather than a strictly literary, mathematical, or architectural material. Code navigation , code structure or code compression , are terms which all belong to a lexical field of spatiality, whether visible or not; the aesthetic properties of source code are tightly related to this apprehension and revealing of conceptual spaces constructed from machine-readable lexical tokens represeting problem domains—or, in other words, thought-stuff ( Brooks Jr, 1975) .

Aesthetic properties of source code were deduced from an empirical approach. We identified the different lexical fields that programmers referred to as they justified their aesthetic judgments on program texts. Specifically, we have identified how references to other fields of activity were used as a metaphorical device in order to better qualify source code (e.g. "source code is like literature... ").

Literature acts as a metaphor for source code through the mapping of linguistic tokens as the building blocks of both natural language texts and program texts (see Representing textual worlds in literature ), while the architecture metaphor includes spatiality and habitability, along with an explicit dimension of function (see Function, style and matter in architecture ) and the mathematics metaphor works through a mapping on abstract conceptual structures and strive for elegance (see Aesthetics and heuristics in mathematics ). We saw that the metaphorical mapping of each of these source domains ultimately reveal and hide particular aspects and aaffordances of source code.

Literary aesthetics facilitate the comprehension of the scope of variables and of the intent of the programmer in relation with the problem domain. They denote the purpose and intent of specific values, expressions, declarations and statements in a natural language, with a potential both for poetic evokation, cryptic obfuscation, or plain misinterpretation. Despite Yukihiro Matsumoto and Donald Knuth's statements that writing source code is a literary art ( Knuth, 1984 Matsumoto, 2007) , this turns out to only be partially true: the most literary parts of source code—comments—are also the parts that are the most decoupled from the actual source code, and are entirely invisible to the machine.

A strictly literary understanding of source sets aside the particularities of the reading process of source code and the temporal control of the writer. A traditional, natural language literary work will assume a linear, front-to-back readership, while source code is defined by its potential ability to jump from any part of the text to any other part of the text. Given this radical difference, references to architectural aesthetics help to establish structural patterns of familiarity and spatiality. Even though it does not operate on concrete, "natural" space, the quality of the disposition and combination of the application components on the source code page enable a better navigation of the source code's conceptual space. Furthermore the metaphor of code as literature also hides the differences in authorship: literature often assumes a single author, while code is in majority written collaboratively, in such an intertwined way that it is complicated to attribute the origin of program texts to a single person (as in the tracing of the authorship of

fast_sqrt_c


float Q_rsqrt(float number)
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y = number;
    i = *(long *)&y;           // evil floating point bit level hacking
    i = 0x5f3759df - (i >> 1); // what the fuck?
    y = *(float *)&i;
    y = y * (threehalfs - (x2 * y * y)); // 1st iteration
                                         //  y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration,
                                         // this can be removed

    return y;
}

- This particular implementation of a function calculating the inverse square root of a number has become known in programming circles for both its speed and unscrutability.

), a complication which increases with time and the modification of program texts.

This reduction of a vast conceptual space to natural language representations, and presented as clear, delimited set of interrelated components reveals the tension in source code between form, function, and the fundamental concepts of computation. In this respect, mathematical aesthetics enable the condensation of knowledge and insight in the least amount of tokens, minimizing noise, and related to poetic expression. Particularly, this ability of representing complex ideas into simple terms is a process of compression shared across poetry, architecture and mathematics, and resulting in an elegant structure.

The architectural metaphor of source code further confirms this structural aspect nature of source code. In architecture, a building ultimately enables flows of people within a static configuration. Similarly, one can consider source code as the static structure within which the dynamic processes of computation are executed, as illustrated by the term control flow or leaky abstractions . In a sense, then, source code can be considered as the blueprint of software, just as a floorplan can be considered the blueprint of a building—even if such floorplan, in this case, would need to be at the 1:1 scale. Structure for computational processes, then, but also structure for humans. As discussed in Compression and habitability in functional structures , the formal arrangement of source code which enables a programmer to inhabit it, to feel at ease in reading and modifying such source code is also positively valued. The structural metaphor of architecture thus works at these two levels.

The maxim form follows function emanates from the field of architecture and therefore allows us to highlight the requirement of function in the definition of source code aesthetics. software needs to be functional in order to be aesthetically judged, and aesthetics facilitate the programmer's understanding of what a program text's function is. This functional aspect also corresponds to a distinction between the essential and the superfluous or, in architectural terms,, between the decorative and the load-bearing. In both architecture and programming, there are aguments being made for the decorative, as a communicative device for a human touch, while the load-bearing element maps to the elegant engineer, the rather impersonal construction which can nonetheless do the most with the least.

Finally, thinking of code as architecture allows us to highlight the notion of craft in the appreciation of well-written source code. Software craftsmanship is both an approach to detail as a particular relationship to material, tools and knowledge. It is a pendant to an overall architectural structure in which a bird's eye view of folder, files, variables and function declarations can provide a grasp of the overall arrangement and style of the software described by the program text. At the micro-level, an architectural approach to source code raises the question of its status as matter to which one can shape into functional structures. The carefully assembling of a program text, by programmers as craftpersons, ultimately reveals the materiality of source code as a medium. A crafted program text takes source code as a material; a cognitive material, but a material nonetheless, a kind of thought-stuff . The attention to detail, superfluous for the amateur practitioner, nonetheless communicates a certain kind of know-how (see Knowing-what and knowing-how ) in the places where one can express their individuality, or focus on a more impersonal and altruistic approach, thus displying a deep understanding of what they are doing.

This cognitive element is further revealed by the mathematical metaphor. The most obvious connection is through the common use of a formal syntax in order to express complex concepts. While initially terse and foreign, such a language enables a certain kind of play. One can reduce an expression, replace its terms, consider problems from a different angle, at different scales, under different conditions. etc. This play with symbols reveals a certain malleability and modularity of its object, and further supports our approach of code as a cognitive material. As shown in Mathematics , aesthetics in source code, as in mathematics, can be seen as both a by-product and a goal to be reached, implying a certain ideal formal configuration of symbols for a given problem. Conversely, this relationship with cognition also operates at the earlier stages of writing code: as a heuristic, a positive aesthetic judgment on a work-in-progress leads the programmer and the mathematician alike in the right direction of a correctly functioning program text or demonstration.

Most visible in the hacker aesthetic Hackers , code as mathematics makes obvious the relationship of aesthetics with intellectual engagement. Whether it is to understand certain subtleties at the algorithm design level, at the programming language use level, or at the hardware configuration level, aesthetics have the function of communicating the author's knowledge to the reader, either by making the syntactic representation the simplest possible, while not compromising with the integrity of the underlying concepts or by making this representation so obfuscated that these formal arrangements anounce a pleasurable brain-twisting puzzle. In any case, the aesthetic experience of code, just like the aesthetic experience of mathematics is not one which relies on immediate, emotional reaction. Rather, it demands from the reader a focused attention and cognitive abilities of modelling the space time of a program text; in turn these two requirements are impacted by formal arrangements, making concepts harder or easier to grasp.

Aligning with the conceptions of code as literature and code as architecture is that of elegance . We defined in Ideals of beauty the notion of elegance, from poetry to engineering, as the ability to do the most with the least. Mapping these aesthetic metaphors onto soure code confirmed that a program text written in a way that uses the minimum amount of required tokens in order to perform the fullest version of its function is one of the most praised aesthetic abilities. Robust, sparse and straightforward program text is considered a beautiful achievement, one in which function, structure and skill are intertwined to produce the most with the least. Here, this definition of "the most" is not only one based on quantitative performance such as CPU cycles, but also on its easing of the cognitive burden in understanding and engaging with the technical object that is source code.

However, what the mathematical metaphor does not show is the relationship between elegance and context. What "the minimum required" and what "the fullest version of its function" depend on various factors, from external technical requirements, programming language, number and skill of collaborators, etc., something which mathematics, in its presentation as a lingua unversalis , sets aside.

Overall, then, the overlap of these metaphors have led us to identify two main aspects: semantic compression and spatial exploration. Semantic compression concerns the ability of a notation to express complex concepts through quantitatively and qualitatively simple combination, while spatial exploration concerns the ability of source code to be structured in such a way that is both evocative (the broad shape of things have a relative connotation to what these things can do) and sustainable (the structuring of a function ensures that a given action will not have unexpected side-effects), with the ultimate purpose of facilitating the navigation of program texts by the programmer. Furthermore, rather than being opposites of one another, each reference contributes to the purpose of source code aesthetics by clarifying the structure of the code at multiple levels and dimensions.

Ultimately, all of these elements thus relate to communication and cognition, and to how the (invisible) purpose and intent of the code can be communicated in (visible) lines of a language straddling the line between machine and human comprehension. Literature, architecture, mathematics and engineering all rely on a set vocabulary to enable through understanding; their efficiency at doing so can be assessed by the reader's correct or erroneous estimation of what are the fundamental concepts of what is being communicated to them. Keywords, tokens and beacons are all elements which have been found to structure the writing and reading of source code, allow the programmer to establish a cognitive map of the abstract structure of the program text.

This final correlation of aesthetics with the communication of intent and purpose now leads us to address our third research question: the connections between form and function in source code. We have shown that, in the case of software engineers, aesthetics can be used to facilitate understanding in a functional context, or that, in the case of hackers, aesthetics can be a display of a deep understanding of the material at hand. As for scientists and poets, aesthetics perform a role of compression of complex concepts (be they scientific or poetic) into a concrete form. Aesthetics are both conditioned to, and signifiers of function.

However, the most crucial aspect of the aesthetics of source code is that they any positive evaluation is negatively affected if the executed code does not perform as intended, such as if there is a mismatch between what the original programmer(s) intended, and how the actual machine behaves. There is very little guarantee of such a synchronization: the programmer might say something and the machine do something different, and it is not clear what or where exactly is that difference. In this case, the program text, as the only component of software taken into account by the computer, is also the only canonical source of investigation into fulfilling the functional nature of the program.

In this sense, the quality of an aesthetic property (e.g. consistence or coherence) can be judged on whether it adequately represents a given concept, behaviour or intent. The unique aspect of this aesthetic judgment of source code is that there are indeed two judges: the human(s) and the machine, whereby the possibility for human assessment is dependent on a presupposed machine assessment. In all the different groups of writers identified, correctness always conditions pleasantness .

This is verified only to a certain extent for poets, whom do not require a program text to be productive in order to be given an aesthetic value. Still, in the case that the poet does write a syntactically correct text from a machine perspective, and a semantically evocative text from a human person, the artistic quality of the work created emanates from this technical feat. Traditionally, the effect is similar: by respecting particular formats (e.g. the sonnet, the haïku or the alexandrine verse), the poet displays technical virtue along with emotional sublimation. One understanding of the poem's functioning (rather than its producing) is how each chosen words manage to fulfill the expectation of the technical form and the evocative content. One might say that a particular choice of word or line "works" at a certain location but "doesn't work if moved at another part of the poem.

Poems also perform a kind of function that is not as immediately productive as a database query. By joining the technical and the emotional, they perform a more symbolic function about the space of possibilities and the space of the thinkable given to humans. The poet's dual display of skill relates to a conception of art as a connection between the technological and magical highlighted in subsection Software as a relational object . Displaying artistic creativity within source code can thus be seen as a way to enchant the technology of software, by representing it as a technically excellent crafted object, imbued with poetic expressivity.

This tight coupling of function and appearance, something already very present in architectural aesthetics (see section Function, style and matter in architecture ), also echoes with Nelson Goodman's theory of art as composed of a language system used to express complex ideas (see Source code as a language of art ), and practices of craft and toolmaking (see Crafting software ). Source code, while remaining subject to function, nonetheless allows for a certain versatility in the expression of the concept (ranging from explicit to implicit); in turn, this expressivity depends on a given level of skill and practice in the idiosyncracies of the programming languages used and the programming communities in which the source code is written (see Styles and idioms in programming ). The proficiency in a language involves a "right way to do things", resulting in "things looking good", and hints at the fact that there is a certain level of expertise needed to assess the quality of the aesthetic properties of a program text, and that the novice cannot be expected to provide an informed aesthetic value judgment.

Findings

What does source code have to say about itself?

How does source code relate to other aesthetic fields?

How do the aesthetics of source code relate to its function?