see tex file
we start our journey here. basically, we look at what programmers say when they talk about beautiful code.
we see there are different kinds of lexical fields of beauty, also by including examples, which might be devoid of context for now
but we also see that all these kinds might relate to understanding. so we turn to this next
so what’s up with understanding? turns out code is tricky to understand because
it has to talk to machines
and to humans
overall principles: http://denninginstitute.com/pjd/GP/gp_summary_toplevel.html
slide 25 shows the relation between quantity and quality and code and speech in computer systems link
https://www.amazon.com/What-Robots-Studies-Cognitive-Systems/dp/9401050872
but maybe we can get more by relating it to other fields of aesthetics and see what they have to offer
complexity to understand streams: https://hapoc2021.sciencesconf.org/data/pages/_Biboudis_streams_hapoc2021_slides.pdf
we see how programming languages deal with understanding between computers and humans, and how they have to provide an interface to deal with meaning.
A theorem, however, is (see above) only useful if we can apply it under a minimum number of clear conditions. In the same way the usefulness of a subroutine (or, in a language, a grammatical instruction) increases as the chance decreases, that it will be used incorrectly. From this point of view we should aim at a programming language consisting of a small number of concepts, the more general the better, the more systematic the better, in short: the more elegant the better src
we also look into language-dependent features, and language-independent features.
so we conclude on language as a material to embody a theory of semantico-spatial cognition
here, we look at how literature, architecture and maths deal with beauty and understanding
now that we have stronger concepts, let’s dive back into code
here is where we deploy our theory.
https://queue.acm.org/detail.cfm?id=1039535
This recalls the idea of \emph{semantic proximity}, extracted from our analysis of programmers’ comments and opinions on what they found makes code beautiful. Such a pattern does however contrast with the nature of object-oriented programming, in which inheritance (and subsequent local abstraction of subclasses) is considered best practice. Gabriel calls this idea \emph{locality}: it is
\begin{quote} that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. \citep{gabriel_patterns_1998}\footnote{He adds that this isn’t so much an issue if one is using a powerful and efficient IDE—a remark which opens up the question of the role of tools and technical mediators in the reading and writing process…} \end{quote}
as we have our typology, we realize that they are all a bit all over the place. is there something that binds them all? yes, programming languages, so we turn to that next to see how a medium/object/material can meet all those at once
the aesthetics of code is the symbolic progression from word to structure to idea, with each of these configurations happening at different moments and different levels of expertise in programmers, and assigning different roles to the lexical tokens visible on the screen.
and then poetics as an opening