icon to open the header menu
Aesthetic ideals in programming practices

Aesthetic domains

The qualifiers programmers use when they relate to the aesthetic qualities of source code (the way it looks) or the aesthetic experience that it elicits (the way they feel) has shown both a certain degree of coherence, and a certain degree of elusiveness. Subjectively, programmers associate their experience of encountering well-written code as an aesthetic one. However, on a normative level, things become complicated to define: as we have seen in the previous section's discussion of forum exchanges, beauty in source code is not explicited in and of itself.
Next, we inquire into the specific domains that programmers use to illustrate the qualities of source code; we will examine in which capacity these are being summoned in relation to code, and how they help us further delineate the aesthetic qualities of source code. The assumption here is that a medium—such as source code—is a means of expression, and different mediums can support different qualities of expression; additionally, a comparative analysis can be productive as it reveals the overlaps between these mediums. Since there seems to be some specific ways in which code can be considered beautiful, these adjacent domains, and the specific parts of these domains which create this contingency, will prepare our work of defining source code-specific aesthetic standards.
To do so, then, we will look at the three domains most often conjured by programmers when they mention the sensual qualities of, or the aesthetic experiences elicited by, source code: literature, mathematics and architecture. While there are accounts of parallels between programming and painting ( Graham, 2003) or programming and music ( McLean, 2004) , these refer to the painter or musician as an individual, rather than to the specific medium, and there are, to the best of our knowledge, no account of code being like sculpture, film, or dance, for instance.

Literary Beauty

The medium of expression most obviously similar to code is literature: perhaps because they both require, fundamentally, the use of alphanumeric characters laid out on a two-dimensional plane. Similarly, they both involve syntax and semantics interplay in order to convey meaning to a reader. Code as literature , then, focuses on this similarity of natural language and computer language, on its narrative, rhetorical and informative properties, and even on its ability to mimick the traditional forms of poetry.

Code as a linguistic practice

In Geek Sublime , Vikram Chandra, novelist and programmer, lays out the deep parallels he sees between code and human language, specifically sanskrit. While stopping short of claiming that code is literature, he nonetheless makes the claim that sanskrit is, as a set of generative linguistic rules to compose meaning, a distant ancestor to computer code ( Chandra, 2014) , a fact corroborated by Agathe Keller in her studies of the Āryabhaṭa ( Keller, 2021) . Sanskrit, like computer code, relies on context-free rules and exhibits similar properties as code, such as recursion and inheritance.
With a similar syntactic structure between sanskrit and code, the former also exhibits a " search for clear, unambiguous understanding " through careful study, a goal shared by the writers of source code. Specifically, the complexity of the linguistic system presented both in sanskrit and in machine language implies that enjoyment of works in either medium happens not through spontaneous, subjective appreciation, but through "conoisseurship", resulting from education, experience and temperament ( Chandra, 2014) .
Similarly, in Words Made Flesh: Code and Cultural Imagination , Florian Cramer touches upon code's ability to do things, in order to inscribe it differently in a historical development of linguistics, connecting it to the symbolical works of the kabbalah and Lebniz's Ars Combinatoria . Code, according to Cramer, is linguistic, not just because it is made up of words, but because it acts upon words, influencing what we consider literature and human-language writing:
The step from writing to action is no longer metaphorical, as it would be with a semantic text such as a political speech or a manifesto. It is concrete and physical because the very code is thought to materially contain its own activation; as permutations, recursions or viral infections. ( Cramer, 2003)
Those permutations and recursions are used in the different ways: natural language writers have attempted to apply formulas, or algorithms, to their works, from the Oulipo's Poèmes Algol to Cornelia Sollfrank's Net.Art Generator . The properties that Cramer identifies in machine languages—tensions between totality and fragmentation, rationalization and occultism, hardware and software, syntax and semantics, artificial and natural—are ascribed to the interaction between program and expression, through the shape of those combinatorial poetics ( Cramer, 2003) . This resemblance, or Familienähnlichkeit , to other forms of linguistic expression, is explored further by Katherine Hayles' work on speech, writing and code. Specifically, she sees the linguistic practices of humans and intelligent machines as influencing and interpenetrating each other, considering code as language's partner ( Hayles, 2004) .
Hayles looks at how both literature and code can be expressive in both a syntagmatic and paradigmatic manner. In the former, the meaning spread across the words of a sentence is considered fixed in literature, while it is dynamically generated in source code, depending of the execution state and the problem domain. In the latter, the meaning across synonyms in a (program) text is always potential in literature, but always present in code, thus highlighting different levels of interpretation ( Hayles, 2004) . If code is a form of linguistic system, then it is a dynamic one in which the semantic charge is at least as volatile as in literature, but which possesses an additional dimension , as orality, literacy and digitality complement each other all the while remaining media-specific.
Code can thus be considered a linguistic system in the technical sense, having a syntactic ruleset operating on words, it seems to also be a linguistic system in the cultural sense. As such, it deals with the occult, the magical and the obscure, but also exhibits a desire to communicate and execute unambiguous meaning.
This desire for explicit communication led literacy scholars to investigate source code's relationship to rhetoric. While digital systems seem to exhibit persuasive means of their own ( Bogost, 2008)  ( Frasca, 2013) , the code that underpins them also presents rhetorical affordances. The work of Kevin Brock and Annette Vee in this domain has shown that source code isn't just a normative discourse to the machine, but also an argumentative one with respect to the audience: it tries to persuade fellow programmers of what it is doing. From points being made in large-scale software such as Mozilla's Firefox web browser, to more specific styles in job interviews, source code presents worldviews in its own specific syntax ( Brock, 2019) .
The connections of code to linguistics happens thus at the technical and cultural levels, insofar as it can allow for the expression of ideas and arguments, straddling the line between the rational and the evocative. We now turn more specifically to two instances of program code being considered a literary text, by leading programmers in the field: Yukihiro 'Matz' Matsumoto and Donald Knuth.

Code as text

Perhaps the most famous reference to code as a literary object is to be found in Donald Knuth's literate programming . In his eponymous 1984 article in The Computer Journal , Knuth advocates for a practice of programming in which a tight coupling of documentation with source code can allow one to consider programs as "works of literature" ( Knuth, 1984) . It is unclear, however, what Knuth entails when he refers to a work of literature55 .
Literate programming, a direct response to structured programming, enables the weaving of natural language blocks with machine language blocks, in order to be able to compile a single source into either a typeset documentation of the program, using the TeX engine, or into a source file for a Pascal compiler. The literary, here, is only a new set of tools and practices of writing which result in a publishable work , rather than a literary work , in which the program is described in natural language, with source code being interspersed as snippets throughout. As this approach fits within Knuth's interest in typesetting and workflows of scientific publications, it first locates the relationship between literature and programming beyond this formal level.
Still, his aim remains to support a clear understanding of a program by its reader, particularly emphasizing the complexity of such tasks. If he proposes something with regards to literature, it is the process of meaning-making through reading, and its cognitive implications:
This feature of WEB is perhaps its greatest asset; it makes a WEB-written program much more readable than the same program written purely in PASCAL, even if the latter program is well commented. [...] a programmer can now view a large program as a web, to be explored in a psychologically correct order is perhaps the greatest lesson I have learned from my recent experiences. ( Knuth, 1984)
For Knuth, then, code is a text: both in the traditional, publisher-friendly way, but also in a new, non-linear way. This attention to the materiality of the program—layout, typesetting—foresees subsequent technological solutions to allow natural language and machine language to co-exist56 . We also note here the phrase " psychologically correct order ", highlighting the psychological dimension involved in a programmer's activity, further developed in  The psychology of programming   . Indeed, code is never read linearly, as most codebases might have an entrypoint but no introduction 57 .
Moving away from this hybrid approach involving both natural and machine texts, Yukihiro Matsumoto, the creator of the Ruby programming language, develops his notion of code as an essay in his contribution to the edited volume Beautiful Code  ( UNKNOWN AUTHOR, 2007) . While he does not deal directly with questions of eloquence and rhetoric, as opposed to Brock and Vee, it does however start from the premise that code is a kind of text, insofar as it has a message being conveyed in a written form to an audience. However, it is not a kind of text which has a specific author, or a specific finite state:
Most programs are not write-once. They are reworked and rewritten again and again in their lived. Bugs must be debugged. Changing requirements and the need for increased functionality mean the program itself may be modified on an ongoing basis. During this process, human beings must be able to read and understand the original code. ( Matsumoto, 2007)
This conception, in which a text remains open to being modified further by subsequent voices, thus minimizing the aura of the original version, and possibly diluting the intent of the original author, echoes the distinction made by Roland Barthes between a text lisible (readerly text) and texte scriptible (writerly text) ( Barthes, 1977) . While the former aligns with classical conceptions of literature, with a clear author and life span for the literary work, the latter remains open to subsequent, subjective appropriations. It is these appropriations, or uses, that give a writerly text its value.
This appropriation is such that a modified program text does not result in a finite program text either; due to its very low barrier to modification and diffusion, program texts can act almost as a dialogue between two programmers. As Jesse Li puts it, building the linguistic theory of Volonishov and Bakhtin:
The malware author is in dialogue with the malware analyst. The software engineer is in dialogue with their teammates. The user of a piece of software is in dialogue with its creator. A web application is in dialogue with the language and framework it is written in, and its structure is mediated by the characteristics of TCP/IP and HTTP. And in the physical act of writing code, we are in dialogue with our computer and development environment. ( Li, 2020)
It is to support this act of dialogue, through code's affordance of rapid modification and redistribution, that Matusmoto highlights simplicity, brevity—his term for elegance— and balance as means to write beautiful code. His last criteria, lightness, applies not to the code being written, but to the language being used to write such code, adding one more dimension to the dialogue: between the writer(s), the reader(s) and the language designer(s), an additional aspect we will return to in  Styles and idioms in programming   .
These two examples argue that source code can be considered a text which needs to accomodate a hybrid of natural and machine languages, new modes of diffusion, and countless possibilities for being rewritten. In this technological environment of programming languages (from WEB to Ruby), the aim is to facilitate the understanding of what the program does, and of what it should do, providing cognitive cues for the programmer who will re-use or modify the program.
There is, however, a remnant of readerly texts in the literary conception of source code. Beyond these theoretical and functional conceptions of code's textuality, a last approach to the literariness of source code can be found in the works of code poetry, in which this ambiguity is embraced.

Code poetry

Daniel Temkin, in his Sentences on Code Art 58 , suggests the ways in which code art (encompassing code poetry, esoteric languages and obfuscated code, among others) touches on code's linguistic features mentioned by Chandra and Cramer, while coming at it from a non-functional perspective, radically opposed to Knuth and Matsumoto.
The ambiguity of human language is present in code, which never fully escapes its status as human writing, even when machine-generated. We bring to code our excesses of language, and an ambiguity of semantics, as discerned by the human reader. ( Temkin, 2017)
The artists whose main medium is source code explore the possibilities of meaning-making through mechanisms usually associated with poetry, in both its spoken, written and executed forms59 . Code poetry is a particular kind of writing source code, one which is focused on the evokative possibilities of machine languages, and on the generative interpretation of its human readers, and away from an explicitly productive function. This is a step further in a direction of semantic possibilities hinted at by Richard P. Gabriel when he mentions the parallels between writing code and writing poetry; in an interview with Janice J. Jeiss, he states:
I'm thinking about things like simplicity -- how easy is it going to be for someone to look at it later? How well is it fulfilling the overall design that I have in mind? How well does it fit into the architecture? If I were writing a very long poem with many parts, I would be thinking, "Okay, how does this piece fit in with the other pieces? How is it part of the bigger picture?". When coding, I'm doing similar things, and if you look at the source code of extremely talented programmers, there's beauty in it. There's a lot of attention to compression, using the underlying programming language in a way that's easy to penetrate. Yes, writing code and writing poetry are similar. ( Jeiss, 2002)
Further exploring the semantic possibilities of considering source code as a possible medium for poetic expression, one can turn to the analyses of code poems in publications such as Ishaac Bertram's edited volume, code \{poems\} and Nick Montfort's collected poems in \#! .
In the former's foreword, Jamie Allen develops this ability to express oneself via machine languages, considering that programmers can have " passionate conversations in Python " or, " with a line in a text file, [...] speak directly to function, material action, and agency "  ( Bertram, 2012) . This is done, not by relying on the computer as a generative device, but by harnessing the form and subject matter of those very machine languages which subsequently can exhibit those generative properties. Focusing on the language part of the machine allows for an interplay between human and machine meanings.
Still, machine semantics are considered an essential device in writing code poetry, and exploring concepts that are not easily grasped in natural languages—e.g. callbacks, asynchronous promises or destructuring assignments. Additionally, the contrast between the source representation of the poem and its execution can add to the poetic tension, as we saw in    , and here in Nick Montfort's All The Names of God (2010) (source in    , and output in    ).
all_the_names_of_god

print"a"x++$...$"x$.,$,=_;redo
- A perl poem with highly condensed syntax  ( Montfort, 2014)
all_the_outputs_of_god

  _atk_atl_atm_atn_ato_atp_atq_atr_ats_att_atu_atv_atw_atx_aty_atz_aua_aub_auc_aud_aue_auf_aug_auh_aui_auj_auk_aul_aum_aun_auo_aup_auq_aur_aus_aut_auu_auv_auw_aux_auy_auz_ava_avb_avc_avd_ave_avf_avg_avh_avi_avj_avk_avl_avm_avn_avo_avp_avq_avr_avs_avt_avu_avv_avw_avx_avy_avz_awa_awb_awc_awd_awe_awf_awg_awh_awi_awj_awk_awl_awm_awn_awo_awp_awq_awr_aws_awt_awu_awv_aww_awx_awy_awz_axa_axb_axc_axd_axe_axf_axg_axh_axi_axj_axk_axl_axm_axn_axo_axp_axq_axr_axs_axt_axu_axv_axw_axx_axy_axz_aya_ayb_ayc_ayd_aye_ayf_ayg_ayh_ayi_ayj_ayk_ayl_aym_ayn_ayo_ayp_ayq_ayr_ays_ayt_ayu_ayv_ayw_ayx_ayy_ayz_aza_azb_azc_azd_aze_azf_azg_azh_azi_azj_azk_azl_azm_azn_azo_azp_azq_azr_azs_azt_azu_azv_azw_azx_azy_azz_baa_bab_bac_bad_bae_baf_bag_bah_bai_baj_bak_bal_bam_ban_bao_bap_baq_bar_bas_bat_bau_bav_baw_bax_bay_baz_bba_bbb_bbc_bbd_bbe_bbf_bbg_bbh_bbi_bbj_bbk_bbl_bbm_bbn_bbo_bbp_bbq_bbr_bbs_bbt_bbu_bbv_bbw_bbx_bby_bbz_bca_bcb_bcc_bcd_bce_bcf_bcg_bch_bci_bcj_bck_bcl_bcm_bcn_bco_bcp_bcq_bcr_bcs_bct_bcu_bcv_bcw_bcx_bcy_bcz_bda_bdb_bdc_bdd_bde_bdf_bdg_bdh_bdi_bdj_bdk_bdl_bdm_bdn_bdo_bdp_bdq_bdr_bds_bdt_bdu_bdv_bdw_bdx_bdy_bdz_bea_beb_bec_bed_bee_bef_beg_beh_bei_bej_bek_bel_bem_ben_beo_bep_beq_ber_bes_bet_beu_bev_bew_bex_bey_bez_bfa_bfb_bfc_bfd_bfe_bff_bfg_bfh_bfi_bfj_bfk_bfl_bfm_bfn_bfo_bfp_bfq_bfr_bfs_bft_bfu_bfv_bfw_bfx_bfy_bfz_bga_bgb_bgc_bgd_bge_bgf_bgg_bgh_bgi_bgj_bgk_bgl_bgm_bgn_bgo_bgp_bgq_bgr_bgs_bgt_bgu_bgv_bgw_bgx_bgy_bgz_bha_bhb_bhc_bhd_bhe_bhf_bhg_bhh_bhi_bhj_bhk_bhl_bhm_bhn_bho_bhp_bhq_bhr_bhs_bht_bhu_bhv_bhw_bhx_bhy_bhz_bia_bib_bic_bid_bie_bif_big_bih_bii_bij_bik_bil_bim_bin_bio_bip_biq_bir_bis_bit_biu_biv_biw_bix_biy_biz_bja_bjb_bjc_bjd_bje_bjf_bjg_bjh_bji_bjj_bjk_bjl_bjm_bjn_bjo_bjp_
- A selected section of the expansive output from .
This poem is the object of close literary critical examination by Maria Aquilina, who notes that [t]he contrast between the economical minimalism of the program and the ordered but infinite series of letter combinations it produces is one of the aspects that make the poem striking  ( Aquilina, 2015) . Building on philosophy and literary theorists, Aquilina situates the expressive power of the poem in its engagement with the concept of eventualization , locating the semantic load of the poem in its existence both in a human-perception of the non-human (e.g. computer time) and the dialogue between source, output and title ( Aquilina, 2015) . In between an infinite output and a one-line hack, All The Names of God is in the form monostiche, a natural language poem composed of a one-line stanza, where the aesthetic quality of minimalism is correlated with its expressive power.
Not only is there an aesthetic of minimalism present in the source, the output also represents the depth (in Hayles's sense) of the medium of writing. In this case, source code also supports academic literary analysis, thus reinforcing a literary conception of source code aesthetics.
From software developers to artists, different kinds of writers seem to equate code as a text, bringing forth multiple reasons to justify such a connection. Beyond the fact that source code is made up of textual characters, we see that these conceptions of code as literature are multiple. One perspective is focused on its need to communicate explicit concepts related to its function (Knuth, Matsumoto, Brock), while a complementary persective embraces the semantic ambiguity which exists in the use of natural language tokens, backed-up by the potential executable semantics enabled by its machine nature (Cramer, Hayles, Montfort, Temkin).
This tension, between functional efficiency of the text, and dramatic expressiveness of the poem, suggests a parallel with scientific practices. This is something that Andrei Ershov points to in his 1972 address to the Joint Computer Conference:
"A professional aesthetic influences and is influenced by the ethical code of a profession, by the technical subject matter of the profession, and by the profession's juridical status. [...] The creative nature of programming does not require special proof. Indeed, I may assert, programming goes a little further than most other professions, and comes close to mathematics and creative writing." ( Ershov, 1972)

Scientific beauty

Rooted in computer science's thought and practice, the aesthetic experiences of source code are also related to the scientific domain. Specifically, it seems to exist in two distinct ways: whether code is beautiful in a similar way that mathematics is, or whether code is beautiful according to principles at play in engineering.

Mathematics

A recurring point in programmers' discussions of beauty in programming is oftentimes the duality of the object of discussion: is one talking about an algorithm, or about a particular implementation of an algorithm? While this thesis is concerned with the latter, we now turn to how this relationship between algorithm and implementation presents a similar tension as the relationship between theorem and proof in mathematics.
Among the few discourses of a direct relation between code and beauty from a mathematical perspective, we can see Edsger Dijkstra's discussion of the implementation of programming languages. In it, he starts from computer science's strong origin in mathematics (e.g. lambda calculus), to show that this relation exists in part through, again, the concept of elegance . Theorems and subroutines are compared as being similar essential building blocks in the construction of a correct system. Correctness as the ultimate aim of both mathematics and programming takes place, he writes, by the use of a limited, efficient amount of those building blocks, resulting in a set of small, general and systemic concepts, in an elegant structure ( Dijkstra, 1963) .
This parallel between source code and mathematics becomes clearer when looking at the kinds of aesthetic effects which mathematics possess. Gian-Carlo Rota, in his investigation into mathematical beauty, distinguishes between mathematical beauty, a property which in turn triggers an aesthetic experience, and mathematical elegance, the concrete implementation thereof.
Although one cannot strive for mathematical beauty, one can achieve elegance in the presentation of mathematics. In preparing to deliver a mathematics lecture, mathematicians often choose to stress elegance and succeed in recasting the material in a fashion that everyone will agree is elegant. Mathematical elegance has to do with the presentation of mathematics, and only tangentially does it relate to its content. ( Rota, 1997)
This separation between the beauty of a mathematical concept (theorem) and its presentation (proof) is reflected in the separation between algorithm and computer program, as McAllister notes. According to him, the beauty of source code is considered closer to the beauty in mathematical proofs, and as such abides by norms of exactness (over approximation) and transparency (over cumbersoneness) ( McAllister, 2005) .
Specifically, mathematical proofs are supposed to fulfill the requirement of what McAllister calls graspability , that is, the tendency for a proof to have the theorem it depends on grasped in a single act of mental apprehension by the reader. This, in turn, provides genuine understanding of the reasons for the truths of the theorem. When seen as a form a mathematical beauty, code is therefore praised in being to convey its function through concrete syntax; and linking aesthetic satisfaction with an economy of thought .
The first to employ such an expression, the mathematician Henri Poincaré describes the rigor of a mathematical process as subsequently obtained by combining this economy of thought, a form of cognitive elegance, with the concept of harmony  ( Poincaré, 1908) . By virtue of mathematics being based on formal languages, this linguistic component introduces a certain kind of structure, and the complexity of the problem domain is made more harmonious by the reliance on such an invariant structure (i.e. the syntax of the formal language used). Source code as mathematics can thus be seen as a cognitive structure, which the elements, based on formal linguistics, can exhibit elegant aspects in their communication of a broader concept.
One can find such connections between mathematical and source code elegance in their conciseness to express established, complex ideas. For instance, the implementation of the Floyd-Warshall algorithm reproduced in    is considered by Sy Brand as eliciting an aesthetic experience ( CPPP Conference, 2022) .
floyd-warshall

template <std::size_t V>
auto floyd_warshall(std::array<std::array<int, V>, V> const &graph) {
    auto dist = graph;

    for(auto k: std::views::iota(0u, V))
        for(auto i: std::views::iota(0u, V))
            for(auto j: std::views::iot(0u, V))
                if(dist[i][k] + dist[k][j] < dist[i][j])
                    dist[i][j] = dist[i][k] + dist[k][j];

    return dist;
}
- Implementation of the Floyd-Warshall algorithm, showing an elegant implementation of a complex theory.
Brand's discussion of his aesthetic experience highlights another aspect of source code beauty: intellectual engagement. In order to appreciate the aesthetics of a program text, one needs to taking an active stance and understand what it is that the code (in the case of    does, the function) is trying to do. Once that is understood, one can then appreciate the way in which the algorithm is implemented—that is, its aesthetics.

Engineering

As we have seen in our discussion of the relationship between computer science and programming as a relationship between the abstract and the concrete, one can see in these two activities a parallel in mathematics and engineering, considered as both scientific endeavours. Engineering is, like programming, the concrete implementation backed by deliberate and careful planning, often with the help of formal notations, of a solution to a given problem60 . Mathematics, from this perspective, can be considered as one of the languages of engineering, among sketches, diagrams, techniques, tools, etc.
Nonetheless, one of the central concepts in the practice of mathematics, elegance, can also be found, along with its connection to source code, in engineering. Bruce McLennan examines such a connection from a more holistic angle than that of a single act of mental apprehension, when looking at a proof. He suggests that aesthetics in engineering also play a cognitive role:
Since aesthetic judgment is a highly integrative cognitive process, combining perception of subtle relationships with conscious and unconscious intellectual and emotional interpretation, it can be used to guide the design process by forming an overall assessment of the myriad interactions in a complex software system. ( Schummer, 2009)
His point is that software is too complex to be easily verified, and that tools to help us do so are still limited. This complexity sets our intuition adrift and analytical resources are not always enough to understand what is going on in a given program text. In order to handle this, he proposes to shift the attention from an analytical to phenomenological one, from the details to the general impression. Engineering, like mathematics, ultimately aim at being correct, albeit in different ways. While the latter can rely on succint formal propositions and representations to achieve this purpose, engineering composes too many moving parts of different nature. The specificity lies in the nature of software engineering's materials:
All arts have their formal and material characteristics, but software engineering is exceptional in the degree to which formal considerations dominate material ones. ( Schummer, 2009)
And yet, the development of his arguments remains on the phenomenological side, distant from the standards of mathematic abstraction. In engineering, he argues, the design looks unbalanced if the forces are unbalanced, and the design looks stable if it is stable. By restricting our attention to designs in which the interaction of features is manifest—in which good interactions look good, and bad interactions look bad—we can let our aesthetic sense guide our design, relying on concepts of efficiency, economy and elegance ( McLennan, 1997) .
The sciences, and specifically mathematics and engineering, have their own set of aesthetics standards, to which source code seems to be connected to. Still, the idea of elegance remains central to both mathematical and engineering approaches, as it measures the number and conciseness of the theory's basic principles, or of the structure's basic components, while keeping the need for an overall effect, whether as enlightenment for mathematics, in which larger implications are gained from a particular way a proof of a theorem is presented, or as an ecompassing gestalt impression in engineering, in which a program that looks correct, would most likely be correct.
Two concepts touched upon by both approaches are that of structure and know-how. While mathematics deal with formal structures to represent and frame the complexity of the world, engineering deals with concrete structures offered as solutions to a specific problem. In both domains, there is also a reference to a certain sense of intuition, which enables cognitive discovery of a functional artefact (whether am abstract theorem or a concrete construction), something we also find when exploring parallels with architecture

Architectural beauty

Beyond a more official understanding of software architecture (see  Software developers   ), architecture is used extensively as a metaphor for code. In this section, we will look at architecture from two complementary perspectives: as a top-down approach, and as a bottom-up practice. This will allow us to touch on notions of structure, form and function, and provides us with another perspective which will bring into light the idea of craft.

Formal organization

Software architecture emerged as a consequence of the structured revolution ( Dijkstra, 1972) , which was concerned more with the higher-level organization of code in order to ensure the quality of the software produced. Such an assurance was suggested by Dijkstra in two ways: by ensuring the provability of programs in a rigorously mathematic approach, and by ensuring that programs remained as readable as possible for the programmers. Structure, complementing syntax, has therefore been an essential component of the intelligibility of software since the 1970s. It is only in the late 1990s that software architecture has been recognized as a distinct discipline, and completely separated from the actual act of programming.
[...] software architectural models are intended to describe the structure and behavior of a system in terms of computational entities, their interactions and its composition patterns, so to reason about systems at more abstract level, disregarding implementation details. ( Garland, 2000)
When Mary Shaw and David Garland publish their 1996 book Software architecture : perspectives on an emerging discipline , they mark the beginning of a trend of so-called architectural practices within the field of software development. These two fields overlap on the topic of structure. Through rigorous, high-level formal organization, the idea was to bring in a more normative approach to writing code, in the hope that this structure would support correctness and efficiency. Building on this need for structure, software architecture has thus developed into an approach to software patterns, modelling and documentation, through the overall processes, communications, inputs and outputs of a system can be formally described and verified.
As an example, the Linux Kernel's architecture can be considered one of the reasons why the project became so popular once integrated into the GNU ecosystem. Along with its distribution license, two of its defining features are speed and portability. While speed can be attributed to its use of C code, also responsible to some extent for its portability, the architecture of the kernel is separated in multiple components which make its extension simple. On one side is the monolithic architecture of the kernel, in which process and memory management, virtual file systems, input/output schedulers, device drivers and network interfaces are all lumped together in kernel space. This tight integration would result in a high-barrier to entry for potential contributors: in such a monolithic system, it is hard to know how a change to a part of the system would affect other parts. However, this architecture also allows for dynamically loadable kernel modules, software components which can be added and removed to the operating system without interference with the core features. This provides a quality of extendability which further contributes to the success of the ecosystem of the Linux ecosystem: there is a reliable core, but also room for extension.
An architecture, such as that of the Linux kernel, thus provides significant semantic content about the kinds of properties that developers should be concerned about and the expected paths of evolution of the overall system, as well as its subparts. The blueprint of the software is made clear enough that it is simple for programmers to find a correct way to contribute to it. Other architectures include, for instance, the client-server architecture (with the peer-to-peer architecture as an alternative), the model-view-controller architecture (and its presentation-abstraction-control counterpart)61 . In all of those cases, a familiar organization of a program texts files and delimitations of its functions lowers the barrier to entry for a programmer, and in this sense contributing to making the program texts writerly texts.
Eric Raymond develops this praise of the Linux kernel in his book The Cathedral and the Bazaar . This essay describes the Linux project, the open-source philosophy it propelled into the limelight, and how the quantity of self-motivated workers without rigid working structures (which is not to say without clear designs) can result in better work than if made by a few, select, highly-skilled individuals ( Raymond, 2001) . While the cathedral is traditionally considered more aesthetically pleasing than the bazaar, in terms of architectural canon, Raymond sides with a bazaar-like model of organization, in which all development is done in public, with a very loose, horizontal contribution structure at any stage of the software lifecycle—as opposed to a tightly guided software project whose development is done by a restricted number of developers. While he doesn't mention specific aesthetic standards in his essay, he does highlight parallels in practices and processes, laying foundations on which to build such standards. Architecture is thus both a model for the planning of the construction of artefacts, and a model for the organization of the persons constructing these artefacts.
Concepts such as modularity, spatial organization or inter-dependence, it turns out, could be applied to both fields. There are only few explicit references to beauty in software architecture design; instead, desirable properties are those of performance, security, availability, functionality, usability, modifiability, portability, reusability, integrability and testability. Perhaps this is due to the fact that the traditional understanding of beauty in terms of external manifestation—decoration—isn't here the main point of software architecture, but rather a functional perception of it.
Overall, this functional conception of architecture can also be found in the trade litterature. For instance, Robert Martin, in the influential Clean Code mentions that the standards of software architecture are based on the 5S japanese workplace organization method, namely:
  • seiri (
  • seiton (
  • seisō (
  • seiketsu (
  • shitsuke (
This confirms the focus on efficiency, organization and proper use, along with the requirement of cleanliness of the tools, workbench and workplace, as a virtue of a good organization. While originally applied to manufacture, Martin makes the case that this can also apply to the knowledge economy—as in the case of programming, with correct naming, correct placement, correct appearance and correct use.
This does not mean that the a priori distant approach to software architecture, one which excludes any concrete writing of source code, negates any sort of personality. Style is indeed present in software architecture. In this context, an architectural style typically specifies a design vocabulary, constraints on how that vocabulary is used, and semantic assumptions about that vocabulary. For example, a pipe-and-filter style might specify a vocabulary in which the processing components are data transformers (filters), and the interactions are via order-preserving streams (pipes). When it comes down to programming such an architectural style, pipes and filters do have a very real existence in the lines of source code. These concepts are inscribed as the |  character for pipes, or the .filter()  method on the JavaScript array type, which itself has different ways of being written (e.g. with an anonymous callback function, or an externally defined function). By virtue of there being different ways being written, one can always argue for whether or not one is better than the other, ultimately resulting in better, clearer program texts.
More specifically, the aesthetic manifestations in the form of source code enter in a dialogue with software architecture. If a good system architecture should first and foremost exhbit conceptual integrity ( Spinellis, 2009) , one can extend this integrity to its source code manifestation. A message-passing architecture with a series of global variables at the top of each file, or an HTTP server which also subscribes to event channels, would look ugly to most, since they betray their original organizational concept. These concrete manifestations of a local texture of incoherence , to paraphrase Beardsley, might be more akin to a code smell , a hint that something in the program might be deeply wrong.
Among architectural styles, it seems that brutalism is the one that tends to be equated the most with styles of programming. Simon Yuill, in the volume edited by Olga Goriunova and Alexei Shulgin, develop a parallel between code art and this style of architecture. Characterized by its foregrounding of the raw materials constituting the building, Brutalism foregoes decoration or ornament to focus on direct utility. Yuill, building on the HAKMEM document circulated at MIT's computer science department in 1972, equates this approach to a coding close to the "bare metal" of the computer, using the Assembly language. Contrary to higher-level languages such as C or Java, Assembly engages directly with the intricacies of specific machines, and underlines the fundamental necessity of the hardware and the need to acknowledge such a primacy. Beyond this materiality, he also equates other architectural values such as modularity present in the work of architects such as Le Corbusier or Kunio Mayekawa, as well as in programs such as the UNIX operating system ( Yuill, 2004) . What we see here is yet another reference from software to architecture, focusing this time on the reality of hardware, and on some theoretical principles similar in postwar Western architecture.
Good source code, from a software architecture perspective, is code which is clearly organized, respecting a formalized blueprint, but does not need to exclude the reality of written lines of source code. A combination of these properties, and acknowledgment of the medium used, can then support an aesthetic experience. As Robin K. Hill mentions in her essay on software elegance:
Brevity by itself can't be enough; the C loop control while(i++ < 10)  may be terse, excelling in brevity, but its elegance is debatable. I would call it, in the architectural sense, brutalism. Architecture provides nice analogues because it also strives to construct artifacts that meet specifications under material constraints, prizing especially those artifacts that manifest beauty as well. ( Hill, 2016)
Both in Yuill and in Hill, we find an interesting parallel in the mention of materiality. Source code might at first seem to be immaterial, consisting of layered representations of electrical current, there is nonetheless a certain kind of tangibility which can be pointed to. Lines being re-arranged, symmetrical or out of alignment, blocks being cut and pasted, these operations all hint at a certain material engagement with the program text, rather than with its abstract model of software architecture. Considering architecture as a bottom-up practice of constructing spaces, one can turn to programmers' discourses on craft to support this material conception.

Crafting software

Considering architecture as a strictly organizational practice does not show the whole picture, as there is another side to architecture, concerned with details rather than with plans, feeling rather than rationalizing.
In their introduction to the field of sofware architecture, Shaw and Garland summon the need to formalise the practice as the practice moves from craft to engineering ( Shaw, 1996) . Originally, the reality of carefully crafted, individualized code and unconstrained approaches to writing code62 was looked down upon by Dijkstra, Knuth and other early software practitioners, for its idiosyncracy and lack of rigor.
However, the conception of programming as a craft has become more and more popular amongst source code writers and readers ( Spolosky, 2003 Seibel, 2009) . For instance, Paul Graham, LISP programmer, co-founder of the Y Combinator startup accelerator and widely-read blogger, highlights the status of programming languages as a medium and craft as a way to approach it, in his essay Hackers and Painters  ( Graham, 2003) . Particularly, he stresses the materiality of code, depicting hackers and craftsmen as people who:
are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters.
So, while links between craftsmanship and programming have existed as self-proclaimed ones by programmers themselves, as well as by academics and writers ( Sennett, 2009 Chandra, 2014) , they have not yet been elucidated under specific angles. Craftsmanship as such is an ever-fleeting phenomenon, a practice rather than a theory, in the vein of Michel De Certeau's tactics, bottom-up actions designed and implemented by the users of a situation, product or technology as opposed to strategies, in which ways of doing are prescribed in a top-down fashion ( Certeau, 1990) .
Explicit knowledge, in programming as in most disciplines, is carried through books, academic programs and, more recently, web-based content that is either structured (e.g. MOOCs, Codeacademy, Khan Academy) or unstructured (e.g. blog posts, forums, IRC channels), but both seem to be insufficient to reach an expert level ( Davies, 1993) . As demonstrated by a popular comic, the road to good code is unclear, particularly when communicated in such a highly-formal language as diagramming ( Munroe, 2011) . Given the fact that an individual can become a programmer through non-formal training—as opposed to, say, an engineer or a scientist—, the learning process must include implicit knowledge.
The acquisition of such implicit knowledge in programming is re-interpretated through fictional accounts designed to impart wisdom on the readers, and taking inspiration from Taoism and Zen ( James, 1987 Raymond, 1996) . From higher-level programming wisdom featuring leading programmers such as Marvin Minsky and Donald Knuth, this sort of informal teaching by showing has been implemented in various languages as a practical learning experience. Without the presence of an actual master, the programming apprentice nonetheless takes the program writer as their master to achieve each of the tasks assigned to them. The experience historically assigned to the master craftsman is delegated into the code itself, containing both the problem, the solution to the problem and hints to solve it, straddling the line between formal exercises and interactive practice ( Depaz, 2021) .
If implicit knowledge can be acquired through a showing and copying of code, software development as a craft presents an additional dimension to this, a sort of piecemeal knowledge . Best represented by Stack Overflow, a leading question and answer forum for programmers, on which code snippets are made available as part of the teaching by showing methodology, this piecemeal knowledge can both help programmers in solving issues as well as deter them in solving issues properly ( Treude, 2017) . Code as such is freely and easily accessible as piecemeals, but often lacks the essential context.
So while programmers are used to acquire implicit knowledge through a process of learning by doing (realizing koans, coding small projects, re-using copied code), we now need to assess how much of it happens through observing. Implied in the apprentice-master relationship is that what is observed should be of good quality ; one learns through ones own mistakes, and through ones presentation with examples of good work63 .
Considering programming a craft therefore raises questions of practice and knowledge, but also of standards of quality. In terms of aesthetic experience, it also hints at the role that style, ornament and function play in the value assessment of a well-crafted program text, just as in a well-crafted program text. These themes will act as a recurring thread throughout this study. Specifically, we will discuss the role of tacit knowledge in the programming practice in  Knowing-what and knowing-how   , and the role of tools in  Tools as a cognitive extension   ; in terms of aesthetics, the place of style between individiual and collective will be analyzed in  Styles and idioms in programming   before developing a further approach code's material aesthetics as refied knowledge in  Material knowledge  
Ultimately, architecture, when referenced by software, includes at least two distinct approaches: a top-down, formal design, and a bottom-up, materialist approach, reflected in how software also refers to architecture: as abstract planning or as hands-on construction, both holding different, but overlapping aesthetic standards. One the one side, we have cleanliness, orderliness and appropriateness, following interpersonal conventions; on the other side, we have a highly individual and informal practice of making which subsists along its explicit counterpart.
Architecture is indeed a field that exists at the intersection of multiple other fields: engineering, art, design, physics and politics. As the organization of space, one can project it onto non-physical spaces, such as software, and the way that it takes shape within the medium of source code will be more thoroughly explored in  Function, style and matter in architecture   . As such, it provides another peek into the relationship between function and form, and how it is mediated by the materials in which a certain structure is built, whether it is a physical structure, or a mental structure which only exists in a written form.
-
When talking about the aesthetics of source code, programmers tend to refer to three main, different domains. Each of these both reveal and obscure certain aspects of what they value in the reading and writing of program texts.
By referring to code as text, its linguistic nature is highlighted, along with its problematic relationship to natural languages—problematic insofar as its ambiguity can play against its desire to be clear and understood, or can play in favor of poetic undertones. The standards expressed here touch upon the specific syntax used to write programming, its relationship to natural language and its potential for expressivity.
Considering the formal nature of source code, scientific metaphors equate source code as having the potential to exhibit similar properties as mathematical proofs and theorems, in which the elegance of the proof isn't a tight coupling with the theorem to be proved, but in which an elegant proof can (and, according to some, should) enlighten the reader to deeper truths. Conversely, these scientific references also include engineering, in which the applicability, its correctness and efficiency are of prime importance: the conception of elegance, accompanied by economy and efficiency, becomes a more holistic one, tending to the general feeling of the structure at hand, rather than to its specific formalisms.
These references to engineering then lead us to the last of the domains: architecture. Presented as both relevant from a top-down perspective (with formal modelling languages and descriptions, among others) or from a bottom-up (including software patterns and familiarity and appropriateness within a given context). These similarities between software in architecture, both in planning, in practice and in outlook, touch upon another subject: the place of formal and informal knowledges in the construction, maintenance and transmission of those (software) structures.
- - -
In this first chapter, we laid out the ground work for our discussion of source code aesthetics. This groundwork is composed of several aspects. First, we have established the diversity of who writes code: far from a homogeneous crowd which would reflect an abstraction conception of "code", code writers include inviduals who might share the practices of engineers, hackers, scientists or poets. While these categories do not have rigid boundaries and easily overlap, they do allow us to establish more clearly the contexts and purposes within which code can be read and written: hacker code and engineer code look different from each other, achieve different purposes than poetic code, abide by different requirements than scientific code. Within each of these conceptions, a judgment of what looks good will therefore be different. A conception of the aesthetics of code seems then, at first, to possess some degree of relativity.
Second, we built on Erik Piñeiro's work to complete a survey of the lexical fields that programmers use when they describe or refer to beautiful code. In so doing, we have highlighted certain desirable properties, such as clarity, cleanliness, and elegance—as opposed to, say, thrilling, moving, or delicate. This survey involved an analysis of textual instances of programmers' discourses: through blog posts, forum discussions, journal articles or textbooks, showing a steadiness in the expression of a certain aesthetic inclination since the beginning of the trade. Additionally, the study of our negative terms pointed further to sensual metaphors of code, using parallels with smell and texture. As a "big ball of mud", a "pile of spaghetti" or full of "smelly corners", ugly code is something where its appearance prevents the reader or writer to grasp its true purpose—what it actually does.
While those terms are being recurrrently used to qualify aesthetically pleasing code, our survey has also pointed to specific domains which programmers use as metaphors to communicate the nature of their aesthetic appreciation: by referring to science, literature and architecture. Each of these metaphors, sometimes simultaneously, select specific parts from their source domain in order to adapt to inform one's appreciation of good source code. Literature brings linguistics, but not narrative; science brings formalism and engineering, but not style nor individuality; architecture brings structure and craft, but not building codes nor end-usage. These domains are thus better understood as the different parts of a Venn diagram, as practictionners attempt to define what it means to do what they do well. This was confirmed by our investigation into the connections between craft and code, looking specifically at how craft practices inform relations between skill, knowledge, function, space and beauty.
The overlap of these different domains has to do, it turns out, with cognitive clarity. Whether wrangling with the linguistic tokens in literary exercises, as Geoff Cox puts it:
It may be hard to understand someone else's code but the computer is, after all, multi-lingual. In this sense, understanding someone else's code is very much like listening to poetry in a foreign language - the appreciation goes beyond a mere understanding of the syntax or form of the language used, and as such translation is infamously problematic. Form and function should not be falsely separated. ( Cox, 2011)
One function of aesthetics might thus be in structuring various pieces of code such that their organization is robust and communicated to others such that it allows for future maintenance and expansion. Another might be writing lines of code in a certain way in order to hint at some larger concepts and ideas beyond their immediate execution result such as in hacking or code poetry. In any case, these domains are all mentioned in their ability to vehiculate ideas from one individual to another—as opposed to, say, elicit self-reflection or sublime physical pleasure. It seems that beautiful code is then both functional code and understandable code.
Before we investigate precisely how aesthetics enable the understanding of computer programs, we will first explicit what makes software a cognitively complex object. The next chapter first highlights the status of software as an abstract artifact , before investigating the means that programmers use to understand the computational phenomena that happen at their fingertips.
icon to reference a footnote
icon to reference a footnote
icon to download the pdf of the thesis