notes - spring 2020


aesthetics in software engineering is not about the program, it’s about the programmer. [[table_of_contents#functional beauty]]

the aesthetics of clarity in executable source code

questions of clarity vs. simplicity (how often do they correspond? oppose?) - is one within time, or within space, or within people? [[table_of_contents#ideals of beauty]]

semantics? -> programming languages have semantics (either denotational or operational, stratchey) -> operational is whatever the machine says, and we can realize/describe/use a symbol without understanding it -> understanding the symbol vs. understanding what the symbol refers to. [[table_of_contents#4 1 - the programming language object]]

there is always a bit of giving up the understanding (linux kernel, APIs, etc.). does it remove the essence or in contrary highlight it? [[table_of_contents#understanding code]]


but tactics could actually be the tip of the manifestation of a yet unknown (the personal?) strategy. two months later: hmmm….

aesthetics as a relationship to the human: if tactics is what makes the individual, strategy is what forces the group > as code matures, there is a switch to a different kind of individuality (mass-production of code)




done (separated in socio-economic categories of practicioners)

object (object of code’s discourse)


“efficient code” depends on knowing the material that you are working with: in the 1970s, it was the compiler (kernighan, elements of programming style). in the 2000s, it might be just the language spec.[[table_of_contents#4 3 3 - language as material]]

code as substitute-material


by understanding what it does, you understand what it is -> relationships of knowledge[[table_of_contents#understanding in craft]]

~~- double-meaning (paloque) is the fact that one can play between machine-language and human-language~~ - - ~~possible triple-meaning with an interplay in conceptual structures (OOP)~~ this is more in the realm of creativity rather than aesthetics. - - ~~creativity might then be that we’re applying software metaphors to classes of concordance~~ - this means that there are two aspects of beautiful code: - one (software engineering), code is being written such that it matches the world/problem-domain/hardware/something else. code should disappear. - two (code art), the world is being encoded to match the limitations of code, opening up new reflexions on this “world”. code should not disappear. - ~~referring to software itself~~ done > hardware, language, algorithm - referring to the environment in which software exists > problem domain, collaborators - - productive software done - - - ~~need to identify the place of uselessness in productivity~~ there are other things that are useless (e.g. erroneous comments), but not aesthetics (that’s what the russian says: that beauty is essential to motivation) - - ~~is it relevant that the domain of application of software can always expand? (from a computational perspective, and from a practical perspective)~~ not really

~~can source code support multiple readings? should it?~~ depends on the context. on the engineering side, it should have only one meaning. on the education side, it could have gradual meanings. on the artistic side, it could have parallel meanings.

however, source code doesn’t seem to have any depth: it is what it does > but hidden depths have to do with the nature/function of the work and the social field in which it exists “What it means for something to have “depth” is that its explanation requires bringing in something like that, something of a different nature, something that does a kind of work no additional detail ever could.” depth is different from detail perceivable (but still hidden) vs. shown looking harder vs. looking differently

Some colleagues (such as Thomas Kühne from Victoria University of Wellington) have taken this further to explicitly define the limited properties of any model. Kühne (2005) describes this in three ways:mapping–(i.e. acknowledging that models are projections of an original);reduction–(i.e. acknowledging that models only represent a selection of relevant properties of the original); and pragmatics–(i.e. acknowledging that any model isaccepted as a proxy for the original only for a specific purpose).[[table_of_contents#means of understanding]]

problematiques importantes: dispositifs et mediations

DRY is actually a problem: humans understand if you repeat them over and over. how do you compromise that? -> proof of the multiplicity of contexts

IS THERE A RIGHT WAY TO WRITE BEAUTIFUL CODE? no, it depends on contexts

concepts / frames


acknowledgment of socio-cultural context within which code poetry emerges, then formal examination of language through which these are written, and circling back towards what these formal uses have to contribute about the purpose/meaning of writing source code poetry (communities, hackers, exploitative economic systems, etc.), and allow for a new perspective on contemporary literature.

~~Is there something that makes something inherently beautiful? As relations to humans/human condition of that time -studying tools.~~ i would argue it’s “attention to readership”

esolangs have a “wimpmode”: esolangs do imply some sort of “skill”. wimpmode is the implication of different readerships


there is also the idea that, even when the code might not work properly, or might barely work (in a functional perspective), it might still work in a literary perspective, the same way that flaubert works, or that beckett works, i.e. does what is intended of it to do (how do we know that? we need critical tools to assess the “aestheticity”). we also need to assess what it is that it is intended to do.

what is the difference between poetics and aesthetics? poetics put together an effect (formal, subjective) vs. aesthetics are more universal, inherent, contemplative? solved

the role of case studies: develop an outline from looking at code, then confront that outline (which will probably be multifaceted) with case studies (2-3) solved

how is the aesthetic value of source code different from the aesthetic value of digital art? irrelevant

checkin three

keep in mind

giving up the understanding in order to understand better (cognitive noise is related to the level of skill) a problem of a lot of research is inventing a new language without inventing new ideas

questions that i need help with

words as problem solvers (in reference to the book pat found, where the author states that programming is treated as a management problem, and not a mathematical one: but in both cases, we’re still talking about source code (and to what extent is it always the “same” source code?), a unique object/practice/paradigm which enables us to solve problems (and now, to what extent are these problems dependent on source code? or is it because source code (as computation) can solve theoretically any problem? and is that beautiful in itself?))

notes from xcoax

while it’s nice to have an overview of humanities at the beginning, it would be interesting to have reconciliation/reconsideration of those views by the end of this paper still important

relationship to art? yes, but tangential question question to the understanding of beauty? yes, but tangential question

~~apparent symmetry vs. assymetry of reading vs. writing~~ taken into account, see above

information is value, or information has value? (just because you have it, or because you know how to use it?)