cover

notes

meta-questions


aesthetics in software engineering is not about the program, it’s about the programmer.

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?

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.

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


STRATEGY VS. TACTICS

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)


questions

tools

typology

done (separated in socio-economic categories of practicioners)

object (object of code’s discourse)


materiality

“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.

code as substitute-material


thoughts

by understanding what it does, you understand what it is -> relationships of knowledge

~~- 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).

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

structure

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

OBSOLETE

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