“with this work we propose to demonstrate the thesis that aesthetics play a particular role in understanding code; the previous research has left many questions unanswered, and the data gathered is still insufficient.”
in the first chapter, bla
in the second chapter, bla
in conclusion, we will attempt to demonstrate, bla, ble and blu
this part will lay out the limits of my object of study, starting from a literature review on specific code studies, and an overview of the best-practices in writing code. from there, I highlight the issue of understanding between humans and machines through the medium of source code, as an ambivalent notion which necessitates a symbolic interface. This concept of understanding is also understood in the light of the different fields of programming practice (professional, amateur (hobbyist+hacker), educational, scientific/academic), fields that will be subject to further definition. This section will conclude in the presentation of the corpus studied and the explanation of the rationale for such a delimitation.
this section provides an overview of previous academic research whose object of study is source code. such a research can be divided into three broad categories: within the domain of engineering, within the domain of the humanities, and within the domain of the arts. each of these categories will allow us to identify the traditions from within which they operate, along with the main concerns and interrogations that arise around source code as an object.
we will see that the engineering field focuses much more on either the fine-grained details of software writing, or on the overall thought processes and economic processes which surround it (best practices, design patterns, software management). this section points out in particular that source code can and should be beautiful.
the humanities, on the other hand, started with focus on a distant, epistemological property of source code (McKenzie, Hayles), to then move into the more precise domain of source code as political expression, as manifestation of politics and as worldmaking, while setting aside the issue of beautiful code (except for paloque berges)
the place of source code in the arts is that of the obfuscated object, of the relegated to the background because of all the focus on output. rather than discussions from existing fields integrating source code, we see instead the emergence of software art, a new field which takes computational processes as its object. however, never is the beauty of these works related to the source which contributes to them. some works on codeworks and code poetry (sondheim, montfort, temkin) do touch upon software aesthetics
we will see that approaches are all different, but that while arts and engineering mention beauty, it isn’t so much the case of the humanities, with a focus rather on cognitive processes and reasoning. this is the hypothesis that is going to be laid out: beauty is understandability.
this section investigates the main challenge that source code tends to address as a human-machine communication tool
this section talks about computation, symbolic logic, math and turing and lambda functions and all that beautiful stuff.
this section talks about the computer as a cognitive tool, as a way to think (rokeby, wolfram), along the lines of algorithmic thinking, coding literacy. this will highlight the necessity of translating concepts from one frame of mind to another (formal vs. informal)
this section focuses on the applied practice of describing things to the computer. who does it, how they do it, and how they relate to it. it would particularly focus on the historical/sociological aspect of it, to start highlighting that there might be one concept of computing, but the reality of interacting with and thinking in terms of computation is not unidimensional. it establishes different categories of people writing source code: researchers, academics (teachers+students), professionals, hackers, amateurs and artists.
this section redefines the concept of understanding, not as human to human, and not as human to machine, but as human to machine to human, and highlights some of the hurdles that appear in terms of collectivity vs. subjectivity. it makes the claim that contrary to writing literature, in which writing is potentially public and reading private, writing source code is a private act (as illustrated by passages like weizenbaum, computer boys) and reading it is highly public. because of a change in concept, i would argue that the change in manifestation of concept is also necessary.
this section builds on the previous conclusions that programming is a multi-faceted act, and that all of these facets, because of the different mental gymnastics they require, need to manifest in different ways. it seems then obvious that we would need to have as broad and varied of a corpus. however, this corpus needs to be composed of source code that is already “beautiful”, in order to extract context-sensitive (i.e. who wrote for whom, etc.) aesthetic attributes.
this part is the theoretical mass of the thesis. it is dedicated to the analysis and development of the place of clarity in the aesthetics of source code, amongst a larger framework for evaluating beautiful code (cleanliness, simplicity, etc.). this investigation of clarity will proceed in an inductive fashion. I will start first from the statements programmers have made about it, and then qualify those statements with contribution from two approaches: on the one hand, literary studies and aesthetic philosophy, and on the other hand, computer philosophy and epistemology. this definitional work will conclude in the description of a set of aesthetic features which relate in different ways to clarity in source code.
this section extracts the features that are recurring in the discourses around beauty in source code. it does so by looking at how practical examples and theoretical statements either converge or diverge and how such statements are modulated by the aforeidentified communities. the common point identified, via the subjectivity of writing code, is the concept of the craft. ultimately, we highlight a certain number of properties which would be indicative of source code being considered beautiful. these include: naming, data structures, double-coding, layout, spatial structuring, reader flow, etc.
this first approach, by comparing both source and comment at the same time (taking texts which are explicitly described as being beautiful), explicitly highlights the requirements for source code to be beautiful.
this second approach contrasts with the functional component of the first one, but nonetheless stands in relationship with it. the creative beauty, by defying traditional beauty standards, does help us highlight, through deviance, what the norm is. these texts on “creative beauty” include the classical perl poetry, code poems, IOCC, code poetry contest, etc.
this subsection also allow us to introduce the concept of craftsmanship and integrate it within a larger tradition of sennett/de certeau/rancière, and connect the practice of programmer to a longer history of craft, a history which in itself has beauty standards TODO
this section justifies the aesthetic framework that is chosen in order to apprehend our body of text. namely, it includes contributions from nelson goodman, kenneth burke, roland barthes, amongst others. perhaps a bit of bakhtin and jakobson and wittgenstein. all in all, it groups together both linguistics and aesthetics in a toolbox which will allow us to further investigate (on a more conceptual level) the elements we’ve excavated in [2.1.2] and [2.1.3]
TODO
looking at the concluding chapters of the Languages of Art, the direct contribution of aesthetics to a mode of cognitive understanding will be explicited in the light of source code and serve as a foundational basis for the rest of our study.
this section oscillate between the scientific reading/writing of a text and the dramatistic (sic) reading/writing of a text as a useful means of apprehending the dichotomy between formal and informal language plays in source code r/w. additionally, the concept of terministic screen (not so far from goffman’s frame analysis) will help us apprehend under which shifting social modes of examination code is being judged.
this section takes on barthes distinction between the readerly and the writerly text and sets it against the practice of open-source software and the tradition of craftsmanship in order to highlight that pleasure/life is being taken from reading readable source code. by looking at additional approaches that barthes has to writerly texts, those which leave room for interpretation, we will be able to identify similarities in source code, first in code structure (modularity), then in code text (conceptual and reader distance) and finally in meta-text, around the comment.
this section concludes our framework construction by enriching it with a relational component, which, while at least implicit in previous contributions, is here expanded on a more social level. it’s hard to separate an exploration of source code aesthetics while side-stepping the heightened features of the social group/s that programmers constitute. it might be possible to consider a piece of source as a “distributed énonciation”, both towards the computer and the fellow human, but also a “delayed énonciation”, because it isn’t as immediate. and because it isn’t immediate, there needs to be an adaptation of the concept of presence in craftsmanship; presence, a requisite in craftsmanship, is manifested through aesthetics. (<- that indeed tells us why we need aesthetics, but doesn’t tell us what these aesthetics are. a closer reading of craftsmanship/aesthetics sources would however have more weight in light of this necessity for presence)
before transitioning
this section explores beauty from the angle of formal logic, TODO. the conclusions could either be formal (like when cramer talks about the symmetrical, repetitive patterns of middle-age monks, or commentaries of mathematicians on e^(i*PI) + 1 = 0), or conceptual. if they’re conceptual, they don’t need to come in to the framework right now. the hypothesis is that those findings will confirm the direciton of these initial sets as established in [2.1]
finally, this section concludes as a recapitulation of how attributes contribute to clarity, by providing a different heuristic than in [2.1]. instead of starting from separate texts and extracting different parts and grouping these parts with others, extracted from other texts, we group our practical and theoretical findings under the umbrellas of several aesthetic features we’ve identified, and described on which levels they operate.
use nouns for variables, verbs for functions, try to mimick an abstracted version of the human language (question: what is the limit of that mimicking the human language -cf. code/render.rb? what integrity does it have to keep? a possible answer is the **data )
as a corollary to metaphor, it’s just about implying something with a minimal sign (the density, as goodman would say, becomes very high)
basically put your variables where you use them, avoid gotos
a word on (automated) consistency
abstracts stuff but not too much: it’s kinda like the UNIX philosophy, where the goal is to do one thing, but do it well
like tobi’s example of using select{} rather than mtx.Lock() in GO. select is slower but something like mtx.Lock() is actually never going to be required in a design document: it’s extraneous when wanting to understand what a software effectively doing. another example of that is the un-necessity of diff noise.
in this part, the set of aesthetic features, composed from both empirical observations and theoretical constructions, is re-examined in the light of the linguistic environments as provided by programming languages. after having elaborated a concept of clarity, I will see if and how programming languages modulate this concept. programming languages will be investigated both as semantic systems, but also as socio-economic systems. by seeing how discourses on clarity vary between programming languages communities, it will be possible to identify such a structural influence and integrate it within our concept of clarity.
this section explores the conceptual definition of a programming language (from a CS and philosophy standpoint), but also the role of language in aesthetics (comparison french vs. german, thomas mann avec ses verbes a la fin)
talk a little bit about formal systems, church and lambda, backus-naur form notation, etc.
each of these sections will highlight both the paradigms as well as the syntactic features of the main categories of programming languages
this section looks at how language-dependent the previously exhibited features of aesthetics might be affected by it
finally, this section will confront our set of aesthetic features to several case studies of existing source code. the choice of these case studies will attempt to be as broad and representative as possible (e.g. commercial, functional, hobbyist, artistic), with the aim of using diverse approaches in order to further qualify the aesthetic approaches defined heretofore.