Understanding source code
Aesthetics in source code are thus primarily related to understanding. In the previous chapter, we have highlighted a focus on understanding when it comes to aesthetic standards: whether obfuscating or illuminating, the process of acquiring a mental model of a given computational object is a key determinant in the value judgment as applied to source code. In this chapter, we focus on the reason for which software involves such a cognitive load, before surveying the means—both linguistic and mechanistic—that programmers deploy in order to relieve such a load.
This requirement for understanding, whether in a serious, playful or poetic manner, is related to one of the essential features of software: it must be functional . As mentioned in our discussion of the differences between source code and software in the introduction, source code is the latent description of what the software will ultimately do. Similarly to sheet music, or to cooking recipes64
, they require to be put into action in order for their users (musicians and cooks, respectively) to assess their value. Therefore, buggy or dysfunctional software is always going to be of less value than correct software (
Hill, 2016)
What Makes a Program Elegant? by Robin K. Hill, 2016. [link]
, regardless of how aesthetically pleasing the source is. Any value judgment regarding the aesthetics of the source code would be subject to whether or not the software functions correctly, and such judgment is rendered moot if that software does not work.The assessment of whether a piece of software functions correctly can be broken down in several sub-parts: knowing what the software effectively does, what it is supposed to do, being able to tell whether these two things are aligned, and understanding how it does it. After deciding on a benchmark to assess the functionality of the source code at hand (understanding what it should be doing), one must then determine the actual behavior of the source code at hand once it is executed (understanding what it is actually doing). Due to its writerly nature, one must also understand how a program text does it, in order to modify it.
This chapter examines what goes into understanding source code: given a certain nature of knowledge acquisition, we look at some of the features of computers that make them hard to grasp, and the kind of techniques are deployed in order to address these hurdles. This will have us investigate the relationship of knowing and doing, the nature of computation (what is software?) and its relationship to the world as it appears to us (how does modelling and abstraction translate a problem domain into software?), and the cognitive scaffoldings set up in response to facilitate that task. Ultimately, we show that, given our definition of understanding, the complex nature of software objects and the diverse techniques programmers use to grasp these objects, aesthetics of source code also hold a significant place in this understanding process, a position we develop in
Machine languages
.
The first part will lay out our definition of understanding, presenting it as a dual phenomenon, between formalism and contextualism. Starting with 20nope! cmdcentury epistemology, we will see that theoretical computer science research has favored a dominantly rational, cognitivist perspective on the nature of understanding, eschewing another mode of understanding suggested by craft practices.
Having highlighted this tension, we then turn to how understanding the phenomenon of computation specifically, starting from an ontological level. The ontological approach will show some of the features of software give it the status of an abstract artifact (
Irmak, 2012)
Software is an Abstract Artifact by Nurbay Irmak, 2012.
, and thus highlighting in which ways is software a complex object to grasp. We then complement this ontological perspective by a more practical, psychological approach. This will show how such a comprehension takes place for situated programmers, at different skill levels, anticipating how aesthetics can fit in this model.Finally, we will conclude with the means that programmers deploy to grasp the concepts at play with software: starting from metaphors used by the general public, we will then see to what extent they differ from the metaphors used by programmers in order to understand the systems they build and work with. In the end, particular attention will be paid to their extended cognition the technical apparatuses used in the development and inspection of source code.
