The role of aesthetics in the understandings of source code

At its most common denominator, architecture is concerned with the gross structure of a system. At its best, architecture can support the understanding of a system by addressing the same problem as cognitive mapping does: simplifying our ability to grasp large system. This phrase appears in Kevin Lynch's work on The Image of the City , in which he highlighted that our understanding of an urban environment relies on combinations of patterns (node, edge, area, limit, landmark) to which personal, imagined identities are ascribed. The process is once again that of abstraction, but goes beyond that, and includes a subjective perspective ( Lynch, 1959) . Moving from the urban planner's perspective to the architects, we see how each individual component contributes to the overall legibility of the system. This section considers how individual structures, through their assessed beauty, offer a cognitive involvement to their participants.

Beauty in architecture is one of the discipline's fundamental components, dating back to Vitruvius's maxim that a building should exhibit firmitas, utilitas, venustas —solidity, usefulness, beauty. And yet in practice, beauty, or the abillity to elicit an aesthetic experience, is not sufficient, and sometimes not even required, for a building to be considered architectural. Even though architecture is usually considered as an art, it is also a product of engineering, and thus a hybrid field, one where function and publicness modulate what could be otherwise a "pure" aesthetic judgment.

This sections looks at architecture through its multiple aspects, to highlight to which extent some of these are reflected in source code¹²⁹ . Through an investigation of the tensions and overlaps of form, function, context and materiality in the built space, we identify similarities in the programmed space. Particularly, we will look at how an understanding of patterns translates across both domains, in response to both architecture and programming's material constraints, due to the physical instantiation of buildings and programs in a situated context.

Particularly, our interest here is with the cognitive involvement in the architectural work. What is there to be understood in a building, and how do buildings make it intelligible? The early theoretical answers to this question is to be found in the work of Italian architects, such as Andrea Palladio, whose conception of its discipline came from ideal platonic form, and mathematical relation between facade and inner elements, as well as Leon Battista Alberti, whose consideration of beauty in architecture, as such an organization of parts that nothing can be changed without detriment to the whole ( Scruton, 2013) ¹³⁰ .

While structure is meant to stand the test of time and natural forces¹³¹ , utility can be assessed by the extent to which a building fulfills its intended function. How the beauty of a building relates to its function, whether it can be completely dissociated from it, or if it is dependent on the fulfillment of its function, is still a matter of debate between formalists and functionalists. Nonetheless, the position we take here is in line with Parsons and Carlson, in that fitness of an object is a core component of how it is appreciated aesthetically ( Parsons, 2012) , and that form is hardly separable from function.

In some way, then, form should be able to communicate the function of a building. Roger Scruton, in his philosophical investigation of architecture, brings up the question of language—if buildings are to be cognitively engaged with, then one should be able to grasp what they communicate, what they stand for, what they express. To do so, he starts from the fact that architectural works are often composed of interconnected, coherent sub-parts, which then contribute to the whole, in a form of gestaltung .

Architecture seems, in fact, to display a kind of 'syntax': the parts of a building seem to be fitted together in such a way that the meaningfulness of the whole will reflect and depend upon the manner of combination of its parts. ( Scruton, 2013)
The Aesthetics of Architecture by Roger Scruton, 2013.

Yet, he develops an argumentation which suggests that architecture is not so much articulated as a language, than as a set of conventions and rules, and that it is not a representative medium (which would imply valid and invalid syntax, as well as intent), but rather an expressive one. Architectural significance, then, relies on the presence and arrangement of those evolving conventions—that is, a style—rather than on the depiction of a subject through an exact syntax. While architecture might not represent content the same way literature does, it is nonetheless expressive, and relies on particular styles—recurring formal patterns and ways of doing—to express a tone, a feeling, or a stimmung in their dwellers.

As identified in Architectural beauty , the similarities between software and architecture can be mapped as symmetrical approaches: as top-down or bottom-up, from an architect's perspective, or from a craftperson's. Since we focus on what a building expresses, we need to consider the source of such an expression. First, we look at how modernism, and the conventions that make up this architectural thought, are the top-down result of the intersection of function, form and industry, and reveal the influence of functional design on the aesthetic appreciation of a work.

The central modern architectural standard is Louis Sullivan's maxim that form follows function , devised as he was constructing the early office buildings in North America. Sullivan's statement is thus that what the building enables its inhabitants to do, inevitably translates into concrete, visible, and sensual consequences.

All things in nature have a shape, that is to say, a form, an outward semblance, that tells us what they are, that distinguishes them from ourselves and from each other It is the pervading law of all things organic and inorganic, of all things physical and metaphysical, of all things human and all things superhuman, of all true manifestations of the head, of the heart, of the soul, that the life is recognizable in its expression, that form ever follows function. This is the law. ( Sullivan, 1896)
The Tall Office Building Artistically Considered by Louis H. Sullivan, 1896.

The value of the building is therefore derived from what it allows the individuals to do: the office building allows them to work, the school to learn, the church to pray and the house to live. To do so, modernist architecture rejects any superfluous decoration, or extraneous addition, as a corruption of the purity of the building's function. In a similar vein, Le Corbusier, another fundamental actor of modern architecture, equates the building with its function, advocating for the suppression of decorative clutter and unnecessary furnishings and possessions, and hailing transparency and simplicity as architectural virtues ( Le Corbusier, 1923) , and culminating in Le Corbusier's assessment that the architectural plan as a generator, and the house as a machine to be lived in.

From this perspective, architectural works are a kind of system, in that they constitute sets of interrelated structural components, where the parts are connected by distinctive structural and behavioral relations; and yet the set of conventions to which Le Corbusier contributes is an abstract representation of this systemic nature. He focuses on the plan as the primary source of architectural quality. For software developers, the equivalent of an architectural plan would be a modelling system such as UML: a language to describe structural relationships between software components, with an example shown in . From a modernist angle, the aesthetic value of a building is thus directly dependent on how well it performs an abstractly defined function for its users, assessed at a structural level.

uml

Description of a software component and its inner relations in the Universal Modelling Language, ( Wikipedia, 2023)
Unified Modeling Language by Wikipedia, 2023.

Just as a two-dimensional floorplan and a three-dimensional building are different, a diagram and a program text are also different. This difference is highlighted throught the process of construction in architecture, and implementation in software development, involving respectively engineers and programmers to realize the work that has been designed by the architect.

It is clear the modernists thought of function as engineering function, and aligned it with engineering aesthetics¹³² . Nonetheless, such a conception of function is definitely machinic, consisting of airflow, heat exchange or drainage, expressing a particular feeling of progress and achievement through industrial manufacturing techniques allowing for new material capabilities against contextual understandings. Here again, the human is but a small part in a dynamic system.

Jacques Rancière, in his study of the Werkbund-inspired architecture, offers an alternative approach, away from the strcit functionality laid out by Sullivan and Le Corbusier before him. The simplification of forms and processes, he writes of the AEG Turbinenhalle in Berlin, which is normally associated with the reign of the machine, finds itself, on the contrary, related to art, the only thing able to spiritualize industrial work and common life ( Ranciere, 2013) .

By paying attention to the role of a detail, and of the human subjectivity and situatedness of the people inhabiting the building, departs form the strict function of an object or of a building, to its actual use. Such a shift moves the aesthetic judgment from a structure-centric perspective (such as Le Corbusier's ideal dimensions), to a human-centric perspective (such as Lacaton & Vassal's practical extension of space and light). Peter Downton reiterates this point, when he states that " buildings and design are often judged from artistic perspectives that bear no relation to how the building’s occupants perceive or occupy the building. " ( Downton, 1998) ; his conception of the artistic here, is one that aligns with Kant's definition of a work that is purposive in itself, and not based on a function that it should fulfill.

One can see a translation of such a self-referential conception of art in the class of building which encompass follies and pavillions. These kinds of buildings are constructed first and foremost for their decorative properties, and only secondarily for its structural and functional properties. Follies, for instance, are individual buildings built on the demand of one specific individual's desire. They aim to represent something else than what they are, with no other purpose than ornament and the display of wealth. Pavilions, in the modern acceptation of the term, are rather displays of architectural and engineer prowess, demonstrating the use of new techniques and materials. By focusing only on design and technical feat, it is this prowess itself that is being represented: the function of the building is only to represent the skill of its builders. For instance, Junya Ishigami's pavillion at the Venice Biennale in 2008, shown in consisted in a very elegant and aerial structure, but whose function was depending on the fact that no living being interacted with it¹³³ .

pavillion

As an artform, architecture provides an immersive and systemic physical environment, and thus shapes human psychology and agency within it, in turn forcing the dweller to acknowledge and engage with their environment. This suggests that, from a formal, top-down approach which considers architecture as possessing a systematic language to be realized exactly at a structural level, there exists a complementary, bottom-up approach, centered around human construction and function.

A counterpoint to this modernist approach of master planning is that of Christopher Alexander. Along with other city planners in the United States, such as William H. Whythe or Jane Jacobs, Alexander belongs to an empirical tradition of determining what makes a built environment good or not, by examining its uses and the feelings it elicits in the people who tread its grounds. He elaborates an approach to architecture which does not exclusively rely on abstract design and technological efficiency, but rather takes into account the multiple layers and factors that go into making

[...] beautiful places, places where you feel yourself, places where you feel alive ( Alexander, 1979)
The Timeless Way of Building by Christopher Alexander, 1979.
[...]

In The Timeless Way of Building , he focuses on how beauty is involved in moving from disorganized to organized complexity, a design process which is not, in itself, the essence of beauty, but rather the condition for such beauty to arise. Alexander's conception of beauty, while very present throughout his work, is however not immediately concerned with the specifics of aesthetics, but rather with the existence of such objects. This existence, in turn, does require to be experienced sensually, including visually.

In this process of achieving organized complexity, he highlights the paradoxical interplay between symmetry and asymmetry, and pinpoints beauty as the "deep interlock and ambiguity" of the two, a beauty he also finds the the relationship between static structures of the built environment, and the flow of living individuals in their midst. In his perspective, then, architecture should take into account the role of tension between opposite elements, rather than the combination of rational and abstract design elements. Such an approach echoes other considerations of tension as a source for stimulating human engagement,such as Ricoeur's analysis of the metaphor (see Literary metaphors ), and the resolution of the riddles presented in works of obfuscated source code (see Hackers ).

He therefore considers a possible aesthetic experience as a consequence of qualities such as appropriateness, rightness to fit, not-simplistic and wholeness. All of these have in common the subsequent need for a purpose, a purpose which he calls the Quality Without a Name ( Alexander, 1979) . This quality, he says, is semantically elusive, but nonetheless exists; it is, ultimately, the quality which sustains life, a conclusion which he reached after extensive empirical research: no one can name it precisely, but everyone knows what it refers to. It is the quality which makes one feel at home, which makes one feel like things make sense in a deep, unexplicable way¹³⁴ . This reluctance to being linguistically explicited is echoed in the work of the craftsman, where a practitioner often finds herself showing rather than telling ( Pye, 2008) , another domain with which software developers identify, explicited in Crafting software .

Among the adjectives used to circle around this quality are whole, comfortable, free, exact, egoless, eternal ( Alexander, 1979) . Some of these qualities can also be found in software development, particularly wholeness and comfort. A whole program is a program which is not missing any features, whose encounter (or lack thereof) might cause a crash. If if a function implies a systematic design, such systematic design is not compromised by the lacking of some parts. Conversely, it is also a program which does not have extraneous—useless—features.

A comfortable program text being is a program which might be modified without fear of some unintended side-effects, without inivisible dependencies which might then compromise the whole. There is enough separation of concerns to ensure a somewhat safe working area, in which one can engage in epistemic probing assuming that things will not be breaking in unexpected ways; being whole, it also provides a higher sense of meaning by realizing how one's work relates to the rest of the construction. The implication here is that comfort derives from a certain kind of knowledge, a knowledge of how things (spatial arrangements, technical specifications, human functions) are arranged, how they relate to each other, how they can be used and modified.

To complement this theoretical pendant, Alexander conducted empirical research to find examples of such qualities, in a study led at the University of Berkley which resulted in his most popular book, A Pattern Language ( Alexander, 1977) . In it, he and his team lists 253 patterns which are presented as to form a kind of language, akin to a Chomskian generative grammar, re-usable and extendable in a very concrete way, but without a normative, quasi-biological component. It turns it out that such a documentation, of re-usable configuration and solutions for contextual problem-solving, had a significant echo with computer scientists.

A whole field of research developed around the idea expressed in A Pattern Language , at the crossover between computer science and architecture¹³⁵ of distinct, self-contained but nevertheless composable components. In Alexandrian terms, they are a triad, which expresses a relation between a certain context, a problem, and a solution. Similarly to architectural patterns, these emerged in a bottom-up fashion: individual software developers found that particular ways of writing and organizing code were in fact extensible and reusable solutions to common problems which could be formalized enough to be shared with others. Patterns enable a cognitive engagement based on a feeling of familiarity, and of recognizing affordances.

Extending from the similarities of structure and function between software and architecture mentioned above, it is the lack of learning from practical successes and failures in the field which prompted interest in Alexander's work, along with the development of Object-Oriented Programming, first through the Smalltalk language¹³⁶ , then with C++, until today, as most of the programming languages in 2023 include some sort of object-orientation and encapsulation. What object-orientation does, is that it provides a semantic structure to the program, reflected in the syntactic structure: objects are conceptual entities, with states and actions, as discussed in Modelling complexity and shown in

representation


class Person {
    int age;
    String name;
    Interest[] interests;

    void greet(){
        System.out.println("hi, my name is "+name+"!")
    }
}

class Interest {
    int priority;
    String name;
}

- An example, written in Java, of how source code can be both a representation oif an individual, as well as exemplify encapsulation.

. This enables such objects to be re-used within a program text, and even across program texts.

The similarities between a pattern and an object, insofar as they are self-contained solutions to contextual situations that emerged through practice, and resulting from empirical deductions, caught on with software developers as a technical solution with a social inflection, rather than a computational focus. Writing in Patterns of Software , with a foreword by Alexander, Richard P. Gabriel addresses this shift from the machine to the human:

The promise of object-oriented programming—and of programming languages themselves—has yet to be fulfilled. That promise is to make plain to computers and to other programmers the communication of the computational intentions of a programmer or a team of programmers, throughout the long and change-plagued life of the program. The failure of programming languages to do this is the result of a variety of failures of some of us as researchers and the rest of us as practitioners to take seriously the needs of people in programming rather than the needs of the computer and the compiler writer. ( Gabriel, 1998)
Patterns of Software: Tales from the Software Community by Richard P. Gabriel, 1998.

The real issue raised here in programming seems to be, again, not to speak to the machine, but to speak to other humans. The programming paradigm of object-orientation aims at solving such complexity in communication. While understanding software is hard, creating, identifying, and formalizing patterns into re-usable solutions turns out to be at least as hard ( Taylor, 2001) . Part of this comes from a lack of visibility of code bases (most of them being closed source), but also from the series of various economic and time-sensitive constraints to which developers are subject to (and echoes those in the field of architecture), and which result in moving from making something great to making something good enough to ship. The promise of software patterns seemed to offer a way out by—laboriously—codifying know-how. Interestingly, while the increase in software quality has been found to result from the application of engineering practices ( Hoare, 1996) , the discovery and formalization of the software patterns takes place through the format of writers' workshops¹³⁷ , presenting a different mode of knowledge transmission.

Throughout his work, Gabriel draws from the work of an architect to weave parallels between his experience as a software developer and as a poetry writer, drawing concepts from the latter field into the former, and inspecting it through the lens of a pattern languages of built concrete or abstract structures. We develop further two concepts in particular, and show how habitability and compression enable an understanding of such structures.

We have seen how source code is an inherently spatial medium, with entrypoints, extracted packages, parallel threads of executions, relative folders and directories and endless jump between files. Reading a program text therefore matches more closely an excursion into a foreign territory whose map might be misleading, than reading a book from start to finish. For instance, builds on a longer history of using the city as a metaphor for large code bases, and visualizes classes, packages and version in three dimensions.

code-city

Given this somewhat literal mapping of source code structure onto urban structure, and given the abstract structure of object-oriented code, a reader of source code will need to find their bearings and orient themselves¹³⁸ . Once the entrypoint is found, the programmer starts to explore the programmed maze and attempts to make sense of their surroundings, as a step towards the construction of mental models.

Both inhabitants in a building and programmers in a code base have a tendency to be there to accomplish something , whether it might be living, working or eating for the former, or fixing, learning or modifying for the latter. Particularly in software, one of the correlated functions of a program text is to be maintainable; that is, it must be made under the assumption that others will want to modify and extend source code. Other pieces of code might just be satisfying in being read or deciphered (as we've seen in source code poetry in Code poetry or with hackers in Hackers ) but this assumption of interaction with the code brings in another concept, that of habitability . In Gabriel's terms, it is

the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. ( Gabriel, 1998)
Patterns of Software: Tales from the Software Community by Richard P. Gabriel, 1998.

In a sense, then, beautiful code is also code that is clear enough to inform action and, well-organized enough to warrant actually taking that action. For instance, writing in the ACM Queue, an anonymous programmer discusses the beauty in a code where the separation between which sections of the source are hardware-dependent and which are not, as seen in

hardware-separation


#define	PMC_VERSION_MAJOR	0x03
#define	PMC_VERSION_MINOR	0x00
#define	PMC_VERSION_PATCH	0x0000

/* * Kinds of CPUs known */

#define __PMC_CPUS() \ __PMC_CPU(AMD_K7, "AMD K7") \ __PMC_CPU(AMD_K8, "AMD K8") \ __PMC_CPU(INTEL_P5, "Intel Pentium")	\ __PMC_CPU(INTEL_P6, "Intel Pentium Pro") \ __PMC_CPU(INTEL_CL, "Intel Celeron") \ __PMC_CPU(INTEL_PII, "Intel Pentium II") \ __PMC_CPU(INTEL_PIII, "Intel Pentium III") \ __PMC_CPU(INTEL_PM, "Intel Pentium M") \ __PMC_CPU(INTEL_PIV, "Intel Pentium IV")

// ...

/*
 * struct pmc_mdep
 *
 * Machine dependent bits needed per CPU type.
 */

struct pmc_mdep
{
    uint32_t pmd_cputtype; /* from enum pmc_cputype */
    uint32_t pmd_npmc;     /* max PMXs per CPU */
    uint32_t pmd_npmc;     /* PMC classes supported */
    struct pmc_classinfo pmd_classes[PMC_CLASS_MAX];
    int pmd_nclasspmcs[PMC_CLASS_MAX];

    /*
     * Methods
     */

    int (*pmd_init)(int _cpu);   /* machine dependent initalization*/
    int (*pmd_cleanup)(int _cpu) /* machine dependent cleanup */
}

- This header file defines the structure of a program, both in its human use, in its interaction with hardware components, and its decoupling of hardware (mentioned in the comments) and software elements (mentioned in the macro and the struct). Additionally, the header does not contain any executable code, thus reinforcing its role as a plan rather than a full building.

. In that example, it is clear to the programmer what the problem-domain is: counter incrementation, high-performance computation, or a specific Intel chip.

hardware-separation


#define	PMC_VERSION_MAJOR	0x03
#define	PMC_VERSION_MINOR	0x00
#define	PMC_VERSION_PATCH	0x0000

/* * Kinds of CPUs known */

#define __PMC_CPUS() \ __PMC_CPU(AMD_K7, "AMD K7") \ __PMC_CPU(AMD_K8, "AMD K8") \ __PMC_CPU(INTEL_P5, "Intel Pentium")	\ __PMC_CPU(INTEL_P6, "Intel Pentium Pro") \ __PMC_CPU(INTEL_CL, "Intel Celeron") \ __PMC_CPU(INTEL_PII, "Intel Pentium II") \ __PMC_CPU(INTEL_PIII, "Intel Pentium III") \ __PMC_CPU(INTEL_PM, "Intel Pentium M") \ __PMC_CPU(INTEL_PIV, "Intel Pentium IV")

// ...

/*
 * struct pmc_mdep
 *
 * Machine dependent bits needed per CPU type.
 */

struct pmc_mdep
{
    uint32_t pmd_cputtype; /* from enum pmc_cputype */
    uint32_t pmd_npmc;     /* max PMXs per CPU */
    uint32_t pmd_npmc;     /* PMC classes supported */
    struct pmc_classinfo pmd_classes[PMC_CLASS_MAX];
    int pmd_nclasspmcs[PMC_CLASS_MAX];

    /*
     * Methods
     */

    int (*pmd_init)(int _cpu);   /* machine dependent initalization*/
    int (*pmd_cleanup)(int _cpu) /* machine dependent cleanup */
}

- This header file defines the structure of a program, both in its human use, in its interaction with hardware components, and its decoupling of hardware (mentioned in the comments) and software elements (mentioned in the macro and the struct). Additionally, the header does not contain any executable code, thus reinforcing its role as a plan rather than a full building.

There are several things which we can identify here. First, the three lines at the top of the listing indicate version numbers, which do not hold any computational functionality, but rather a human functionality: it communicates that this software considers change and evolution as core part of its source code, inviting the programmer reader to further modify it¹³⁹

Second, the line defining the types of CPUs supported by the software is written in human-intelligible way, rather than a cryptic hexadecimal notation¹⁴⁰ . While the CPUs are ultimately represented in hexadecimal notation, the effort is made to render things intelligible to and quickly retrievable from the programmer's memory.

Finally, the struct pmc_mdep is a shorthand notation for "machine-dependent". In an era in which software can theoretically be executed on different hardware architectures, it is welcome to make the difference between the variables themselves, which apply across platform, and the values of these variables, which need to be changed per platform¹⁴¹ . This is a good example of a separation of concerns: it is made clear which parts of the program text the programmer needs to pay attention to, and can change, and which parts of the program texts she needs not be concerned with. For a further example of separation of concerns, one could point a beautiful commit is a commit which adds a significant feature, and yet only change the lines of the code that are within well-defined boundaries (e.g. a single function), leaving the rest of the codebase untouched, and yet affecting it in a fundamental way.

Habitability, then, is a combination of acknowledgment by the writer(s) to the reader(s) of the source, by referring to the evolution over time of the software, along with the use of intelligible names and separation of concerns. This distinction relates to Alexander's property of comfort, by affording involvement instead of estrangement. Still, such a feature of habitability, of supporting life, doesn't specify at all what it could, or should, look like. Rather, we get from Alexander a negative definition:

The details of a building cannot be made alive when they are made from modular parts And for the same reason, the details of a building cannot be made alive when they are drawn at a drawing board. ( Alexander, 1979)
The Timeless Way of Building by Christopher Alexander, 1979.

If modularity itself is at odds with making good (software) constructions, then its implementation under the terms of an object-oriented programming paradigm becomes complicated. Indeed, the technical formalization of the field came with the release of the Design Patterns: Elements of Reusable Object-Oriented Software book, which lists 23 design patterns implementable in software ( Gamma, 1994) . Its influence, in terms of copies sold, and in terms of papers, conferences and working groups created in its wake, is undeniable, with Alexander himself giving a keynote address at the ACM two years after the release. It has, however, been met with some criticism.

Some of this criticism is that patterns are "external", they look like they come from somewhere else, and are not adapted to the code. In this sense, this corroborates Alexander in being wary of constructions which do not integrate fully within their environments, which do not, in an organic sense, allow for a piecemeal growth¹⁴² . If patterns express relations between contexts, problems and solutions, then it seems that one of the main complaints of developers is that they might, one day, look at the code they were working on and see chunks of foreign snippets dumped in the middle to fix some generic problem, with no understanding for specifics, nor fit in the existing structure. This is judged negatively due to its lack of understanding of context offered by those proposed solutions. In this, blindly applying patterns from a textbook might be a solution, but it's not an elegant one. This criticism also finds its echoes in the Scruton's analysis of architectural styles; rules and conventions, while present in architecture, are often adopted only to be departed from—re-interpreted and adapted to the context of the building ( Scruton, 2013) .

One aspect that has been eluded so far is therefore that of the programming languages used by the programmer. Indeed, one doesn't write Ruby like one writes Java, C++, or Lisp. If materiality is a core component of eliciting an aesthetic experience in an architectural context, then programming languages are the material of source code, and offer a specific context to the writing and reading of the program text.

A final criticism to software patterns is that they are language-independent. As such, they are often workarounds for features that a particular programming language doesn't allow from the get-go, or offers simpler implementations than the pattern's¹⁴³ .

While patterns might operate at a more structural level, hinting at different parts of code, and its overall organization, one can also turn to a more micro-level. What can a detail do in our understanding of structures? Sometimes decried, sometimes praised in architecture, the detail fulfills mutliple roles: acting as a meaningful interface, compressing meaning and testifying for materiality.

Both Scruton and Rancière mention the detail as an essential architectural element. Without contributing to the structural soundness of the construction, it nonetheless contributes to its expressiveness. A blend of the cognitive and sensual is also characteristic of Scruton's "imaginative perception", understood as the perception of the details of built structures, and their extrapolation into the imaginary. Indeed, the experience of the user is based on the points at which it sensually grasps its environment: the detail is therefore the point of interaction between the human and the structure. This imagination depends on the interpretative choices in parsing ambiguous or multiform aspects of the built environment. The detail contributes to the stylistic convention of the creation:

Convention, by limiting choice, makes it possible to 'read' the meaning in the choices that are made for style is used to 'root' the meanings which are suggested to the aesthetic understanding, to attach them to the appearance from which they are derived. ( Scruton, 2013)
The Aesthetics of Architecture by Roger Scruton, 2013.

With many external constraints, due to both context and function, the architect or builder does not have much room for personal expression, and it is through details that their intent and their style are being shown. The significance of a detail can be in explaining which conventions the structure adopts, as well as communicating the intent of the creator, by relying on common past experiences. Such resort to known structures is then used in understanding the approach taken to the problem, either in architecture, or in software engineering¹⁴⁴ . Beyond structural style, a significant detail also manages to compress meaning into a restricted physical surface.

Compression is a concept introduced by Gabriel in response to pattern design. In narrative and poetic text, it is the process through which a word is given additional meaning by the rest of the sentence. In a sentence such as " Last night I dreamt I went to Manderley again. " ( Du Maurier, 1938) , the reader is unlikely to be familiar with the exact meaning of Manderley , since this is the first sentence of the novel. However, we can infer some of the properties of Manderley from the rest of the sentence: it is most likely a place, and it most likely had something to do with the narrator's past, since it is being returned to. A similar phenomenon happens in source code, in which the meaning of a particular expression or statement can be derived from itself, or from a larger context. In object-oriented programming, the process of inheritance across classes allows for the meaning of a particular subclass to be mostly defined in terms of the fields and methods of its subclasses—its meaning is compressed by relying on a semantic environment, which might or not be immediately visible.

This, Gabriel says, induces a tension between extendability (to create a new subclass, one must only extend the parent, and only add the differentiating aspects) and context-awareness (one has to keep in mind the whole chain of properties in order to know exactly what the definition of an interface that is being extended really is). Resolving such a tension, by including enough information to hint at the context, while not over-reaching into idiosyncracy, is a thin line of being self-explanatory without being verbose.

For instance, Casey Muratori explores the process of compression in refactoring a program text, first by distinguishing semantic compression from syntactic compression¹⁴⁵ , and then honing in on what makes a compression successful¹⁴⁶ . Transitioning from uncompressed code, shown in

uncompressed



int num_categories = 4;
int category_height = ypad + 1.2 * body_font->character_height;
float x0 = x;
float y0 = y;
float title_height = draw_title(x0, y0, title);
float height = title_height + num_categories * category_height + ypad;
my_height = height;
y0 -= title_height;

{
    y0 -= category_height;
    char *string = "Auto Snap";
    bool pressed = draw_big_text_button(x0, y0, my_width, category_height, string);
    if (pressed)
        do_auto_snap(this);
}

{
    y0 -= category_height;
    char *string = "Reset Orientation";
    bool pressed = draw_big_text_button(x0, y0, my_width, category_height, string);
    if (pressed)
    {
        // ...
    }
}
// ...

- An uncompressed extract of a program text whose function is to display graphical user interface (GUI) elements. The syntax is very granular and redundant. ( Muratori, 2014)

to compressed code, shown in

compressed



Panel_Layout layout(this, x, y, my_width);
layout.window_title(title);
 
layout.row();
if(layout.push_button("Auto Snap")) {
    do_auto_snap(this);
}
 
layout.row();
if(layout.push_button("Reset Orientation"))
{
    // ...
}
 
// ...
layout.complete(this);

- A compressed extract of a program text whose function is to display graphical user interface (GUI) elements. The same functionality as in is achieved, but with fewer lines of code, and a more expressive syntax. ( Muratori, 2014)

, allows the programmer to understand broad patterns about the overall architecture of the program text—here, the function is to display a clickable panel on a user interface.

uncompressed



int num_categories = 4;
int category_height = ypad + 1.2 * body_font->character_height;
float x0 = x;
float y0 = y;
float title_height = draw_title(x0, y0, title);
float height = title_height + num_categories * category_height + ypad;
my_height = height;
y0 -= title_height;

{
    y0 -= category_height;
    char *string = "Auto Snap";
    bool pressed = draw_big_text_button(x0, y0, my_width, category_height, string);
    if (pressed)
        do_auto_snap(this);
}

{
    y0 -= category_height;
    char *string = "Reset Orientation";
    bool pressed = draw_big_text_button(x0, y0, my_width, category_height, string);
    if (pressed)
    {
        // ...
    }
}
// ...

- An uncompressed extract of a program text whose function is to display graphical user interface (GUI) elements. The syntax is very granular and redundant. ( Muratori, 2014)

The difference we can see between the compressed and uncompressed goes beyond the number of lines used for the same functionality. A first clue in terms of semantics is the use of strictly syntactic block markers: { and }. There are here stricly to delimitate a code block, with no semantic meaning to the computer. While the uncompressed listing shows all the separate elements needed for a button to exist (such as x0 , y0 , my_height , etc.), while the compressed listings as encapsulated them into an object called Panel_Layout , thus abstracting away from the programmer's mind the details of such a panel. This encapsulation then enables a further compression of the program: by adding the push_button() method on the layout , the compressed code realizes the same functionality of checking for button presses for each button, but ties it to a specific object and, due to the implementation, includes the name of the button being pressed on the same line as the check happens, rather than a line apart in the uncompressed example.

compressed



Panel_Layout layout(this, x, y, my_width);
layout.window_title(title);
 
layout.row();
if(layout.push_button("Auto Snap")) {
    do_auto_snap(this);
}
 
layout.row();
if(layout.push_button("Reset Orientation"))
{
    // ...
}
 
// ...
layout.complete(this);

- A compressed extract of a program text whose function is to display graphical user interface (GUI) elements. The same functionality as in is achieved, but with fewer lines of code, and a more expressive syntax. ( Muratori, 2014)

By compressing the source code and abstracting some concepts, such as the button, one can also gain understanding about the rest of the program text. By showing details of practices and styles, a programmer can extrapolate from a small fragment to a larger structure. Gabriel calls this idea locality : it is

that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. ( Gabriel, 1998)
Patterns of Software: Tales from the Software Community by Richard P. Gabriel, 1998.

In poetry, compression presents a different problem since, ultimately, the definitions of each words are not limited to the poet's own mind but also exist in the broad conceptual structures which readers hold. However, since all aspects of a program is always explicitly defined, programmers thus have the ultimate say on the definition of most of the data and functions described in code. As such, they create their own semantic contexts while, at the same time, having to take into account the context of the machine, the context of the problem, and the context(s) that their reader(s) might be coming from.

We now see that, within the same need for the appreciation of function, architecture can take opposite approaches: seeing a building as an abstract design, or as a concrete construction. In his 1951 lecture, "Building, Dwelling, Thinking", Martin Heidegger offers a perspective on these two forms of architecture. He equates top-down and bottom-up to, respectively, building as erecting, and building as cultivating. Ultimately, both of these approaches relate to human dwelling in a given location. To dwell is an engagement of thought and of action, one which leads to the construction of buildings in particular locations, arguing for a contextual adequacy of human structures to their environment¹⁴⁷ ( Heidegger, 1975) . This active existence in time and space, allowing for deliberate thought and action and resulting in a better structure also equates to Gabriel's concept of habitability:

Habitability is the characteristic of source code that enables programmers coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently Software needs to be habitable because it always has to change What is important is that it be easy for programmers to come up to speed with the code, to be able to navigate through it effectively, to be able to understand what changes to make, and to be able to make them safely and correctly. ( Gabriel, 1998)
Patterns of Software: Tales from the Software Community by Richard P. Gabriel, 1998.

As Heidegger returns to the etymological root of dwelling ( bauern ) in order to connect it to the possible experience of the world humans can have through language, he grounds our experience in context. His though, between earth, man, techne and construction, hints at the essence that human construction—craft—as a consequence of thought and as a precedence to construction. Taking into account context and materiality, a final connection between software and architecture is actually with the field that predated, and complemented, architecture: craftsmanship.

Architecture as a field and the architect as a role have been solidified during the Renaissance, consecrating a separation of abstract design and concrete work. This shift obfuscates the figure of the craftsman, who is relegated to the role of executioner, until the arrival of civil engineering and blueprints overwhelmingly formalized the discipline ( Pevsner, 1942) . While computer science, through its abstract designs, echoes the modernist architect with its pure plans, the programmer, identifying itself with the craftsman, offers different avenues for knowing artefacts.

The architect emerged from centuries of hands-on work, while the computer scientist (formerly known as mathematician in the 1940s and 1950s) was first to a whole field of practitioners as programmers, followed by a need to regulate and structure those practices. Different sequences of events, perhaps, but nonetheless mirroring each other. On one side, construction work without an explicit architect, under the supervision of bishops and clerks, did indeed result in significant achievement, such as Notre Dame de Paris or the Sienna Cathedral. On the other side, letting go of structured and restricted modes of working characterizing computer programming up to the 1980s resulted in a comparison described in the aptly-named The Cathedral and the Bazaar . This essay described 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 Henningsen, 2020) .

What we see, then, is a similar result: individuals can cooperate on a long-term basis out of intrinsic motivation, and without clear, individual ownership of the result; a parallel seen in the similar concepts of collective craftsmanship in the Middle-Ages and the egoless programming of today ( Brooks Jr, 1975) . Building complex structures through horizontal networks and practical knowledge is therefore possible, with consequences in terms aesthetic appreciations.

Craftsmanship in our contemporary discourse seems most tied to a retrospective approach: it is often qualified as that which was before manufacture, and the mechanical automation of production ( Thompson, 1934) , preferring materials and context to technological automation. Following Sennett's work on craftsmanship as a cultural practice, we will use his definition of craftsmanship as hand-held, tool-based, intrinsically-motivated work which produces functional artefacts, and in the process of which is held the possibility for unique mistakes ( Sennett, 2009) .

At the heart of knowledge transmission and acquisition of the craftsman stands the practice , and inherent in the practice is the good practice , the one leading to a beautiful result. The existence of an aesthetic experience of code, and the adjectives used to qualify it (smelly, spaghetti, muddy), pointed at in Lexical Field in Programmer Discourse , already hints at an appreciation of code beyond its formalisms and rationalisms, and towards its materiality.

A traditional perspective is that motor skills, with dexterity, care and experience, are an essential feature of a craftsman's ability to realize something beautiful ( Osborne, 1977) , along with self-assigned standards of quality ( Pye, 2008 Sennett, 2009) . These qualitative standards which, when pushed to their extreme, result in a craftsperson's style , gained through practice and experience, rather than by explicit measurements ( Pye, 2008) ¹⁴⁸ . Two things are concerned here, supporting the final result: tools and materials ( Pye, 2008) . According to Pye, a craftsperson should have a deep, implicit knowledge of both, what they use to manipulate (chisels, hammers, ovens, etc.) as well as what they manipulate (stone, wood, steel, etc).

The knowledge that the craftsman derives, while being tacit (see Knowing-what and knowing-how ), is directed at its tools, its materials, and the function ascribed to the artefact being constructed, and such knowledge is derived from a direct engagement with the first two, and a constant relation to the third. Finally, any aesthetic decoration is here to attest to the care and engagement of the individual in what is being constructed—its dwelling, in Heideggerian terms.

This relationship to tools and materials is expected to have a relationship to the hand , and at first seems to exclude the keyboard-based practice of programming. But even within a world in which automated machines have replaced hand-held tools, Osborne writes:

In modern machine production judgement, experience, ingenuity, dexterity, artistry, skill are all concentrated in the programming before actual production starts. ( Osborne, 1977)
The Aesthetic Concept of Craftsmanship by Harold Osborne, 1977.

He opens here up a solution to the paradox of the hand-made and the computer-automated, as programming emerges from the latter as a new skill. This very rise of automation has been criticized for the rise of a Osborne's "soulless society" ( Osborne, 1977) , and has triggered debates about authorship, creativity and humanity at the cross-roads between artificial intelligence and artistic practice ( Mazzone, 2019) . One avenue out of this debate is human-machine cooperation, first envisioned by Licklider and proposed throughout the development of Human-Computer Interaction ( Licklider, 1960 Grudin, 2016) . If machines, more and more driven by computing systems, have replaced traditional craftsmanship's skills and dexterity, this replacement can nonetheless suggest programming as a distinctly 21st-century craftsmanship, as well as other forms of cratsmanship-based work in an information economy.

Beautiful code, code well-written, is an integral part of software craftsmanship ( UNKNOWN AUTHOR, 2007) . More than just function for itself, code among programmers is held to certain standards which turn out to hold another relationship with traditional craftsmanship—specifically, a different take on form following function.

A craftsman's material consciousness is recognized by the anthropomorphic qualities ascribed by the craftsman to the material ( Sennett, 2009) , the personalities and qualities that are being ascribed to it beyond the immediate one it posseses. Clean code, elegant code, are indicators not just of the awareness of code as a raw material that should be worked on, but also of the necessities for code to exist in a social world, echoing Scruton's analysis that architectural aesthetics cannot be decoupled from a social sense¹⁴⁹ . As software craftsmen assemble in loose hierarchies to construct software, the aesthetic standard is the respect of others , as mentioned in computer science textbooks ( Abelson, 1979) .

Another unique feature of software craftsmanship is its blending between tools and material: code, indeed, is both. This is, for instance, represented at its extreme by languages like LISP, in which functions and data are treated in the same way ( McCarthy, 1965) . In that sense, source code is a material which can be almost seamlessly converted from information to information- processing , and vice-versa; code as a material is perhaps the only non-finite material that craftspeople can work with—along with words¹⁵⁰ .

Code, from the perspective of craft, is not just an overarching, theoretical concept which can only be reckoned with in the abstract, but also the very material foundation from which the reality of software craftsmanship evolves. An analysis of computing phenomena, from software studies to platform studies, should therefore take into account the close relationship to their material that software developers can have. As Fred Brooks put it,

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. ( Brooks Jr, 1975)
The Mythical Man-month: Essays on Software Engineering by Frederick Phillips Brooks Jr, 1975.

So while there are arguments for developing a more rigorous, engineering conception of software development ( Ensmenger, 2012) , a crafts ethos based on a materiality of code holds some implications both for programmers and for society at large: engagement with code-as-material opens up possibilities for the acknowledgement of a different moral standard¹⁵¹ . As Pye puts it,

[ ] the quality of the result is clear evidence of competence and assurance, and it is an ingredient of civilization to be continually faced with that evidence, even if it is taken for granted and unremarked. ( Pye, 2008)
The Nature and Art of Workmanship by David Pye, 2008.

Code well-done is a display of excellence, in a discipline in which excellence has not been made explicit. If most commentators on the history of craftsmanship lament the disappearance of a better, long-gone way of doing things, before computers came to automate everything, locating software as a contemporary iteration of the age-old ethos of craftsmanship nonetheless situates it in a longer tradition of intuitive, concrete creation.

To conclude this section, we have seen that architecture can offer us some heuristics when looking for aesthetic features which code can exhibit. Starting from the naïve understanding that form should follow function, we've examined how Alexander's theory of patterns, and its significant influence on the programming community¹⁵² , points not just to an explicit conditioning of form to its function (in which case we would all write hand-made Assembly code), but rather to an elusive, yet present quality, which is both problem- and context-dependent.

Along with the function of the program as an essential component of aesthetic judgment, our inquiry has also shown that program texts can present a quality that is aware of the context that the writer and reader bring with them, and of the context that it provides them, making it habitable. Software architecture and patterns are not, however, explicitly praised for their beauty, perhaps because they disregard these contexts, since they are higher-level abstractions; this implies that generic solutions are rarely elegant solutions. And yet, there is an undeniable connection between the beautiful and the universal. Departing from our investigation of software as craftsmanship, and moving through towards a more abstract discipline, we turn to scientific aesthetics.

Function, style and matter in architecture

Form and Function

Patterns and structures

Compression and habitability in functional structures

Material knowledge