notes - fall 2020


who is going to be impacted by this? how does it create discussion/connection?

to read

conceptual blending, form and meaning

metaphors and the main problems of hermeneutics

the metaphorical process as cognition, imagination and feeling

towards a model of text comprehension and production

strategies of discourse comprehension

mit study on cognition

on knowldege in architecture and science

patterns, software and philosophy

software abstract artifact and

elegance in programming language design

systems elegance

ontologies of computer programs

Implementation as: THIS GOES WITH GOODMAN


alexander vs. eisenman

alexander = softdev, habitable vs. eisenman = hack, subversion

reading and writing

there could be different beauties in writing and in reading (case of Mike’s APL) - easier to read vs. easier to type

aesthetic analysis

luigi pareyson: aesthetics and interpretation []


My personal style guide is to copy Erlang: double quotes for text, single quotes for programmatic strings (atoms/symbols). The single quote is slightly more convenient to type on a qwerty keyboard, but text regularly contains single quotes (apostrophes). It also provides a semantic visual shortcut.

I like the concept of semantic visual shortcut, also semantic compression (developed here) - typography is proven to be helpful

this could be an interesting theory about the reading process: []

this is not so much about code aligning with standards of literature, but maybe aligning to the standards of both epistemology and architecture, architectural knowledge

programming languages

when we talk about esolangs, we are designing a perspective for someone to think through. -daniel temkin src

There’s a lot of attention to COMPRESSION, using the underlying programming language in a way that’s easy to penetrate - richard gabriel src

conceptual art aims at communicating concepts, ideas. experimental art don’t know what they aim at but are motivated by an aesthetic criteria. (richard gabriel, keynote science is not enough)

the question of operational meaning vs. denotational meaning should be explored. what means what to the computer? (and what is the role of the stack in this whole thing)

procedural rhetoric is just a very high level of programming semantics. processes with meaning assigned to it. <- this further extends the gradient.

a class within a class link is a visual/spatio-mental pattern which means “complexity”, “unmaintainability”, “unsustainability”

bad patterns make possible the kind of actions which result in bad patterns?

Abstraction in programming is the process of identifying common patterns that have systematic variations; an abstraction represents the common pattern and provides a means for specifying which variation to use. An abstraction facilitates separation of concerns: The implementor of an abstraction can ignore the exact uses or instances of the abstraction, and the user of the abstraction can forget the details of the implementation of the abstraction, so long as the implementation fulfills its intention or specification. (Balzer et al. 1989)

Compression is the characteristic of a piece of text that the meaning of any part of it is “larger” than that particular piece has by itself. This characteristic is created by a rich context, with each part of the text drawing on that context—each word draws part of its meaning from its surroundings. Piecemeal growth is the process of design and implementation in which software is embellished, modified, reduced, enlarged, and improved through a process of repair rather than of replacement

meeting with advisors


the intent overall is to see to what extent there is an overlap between each of those communities of practice

next steps:

chat w/ alexandre

chat w/ nick

whole email

Your four categories could be refined a bit. I think data scientists working for businesses are very much like the “academics” you identify, in that they don’t ship their software to others and their outcomes are external research and insight. A minor issue, but it leads to thinking about the distinction between custom software development for corporate clients (only one piece of software is made) and massively distributed games, apps, operating systems, etc. that run on a variety of platforms and need to be maintained in that context. What a “software engineer” does in these contexts is fairly different, and even if the category holds, I would expect different style guides (for instance) to be used in both cases.

Definitely. These are not at all strictly-defined categories (for now), but rather a heuristic to get past the assumption of “there is only one kind of code”. So rather than distinguishing professions/social groups, I could make a distinction between purposes of code-writing, which would fit better the argument of contextual meaning/contextual aesthetics that I’m pushing forward. This is how I see these four categories:

I wonder if source code can ever explain “why” it does anything outside of its own systematic workings. This perhaps comes to the issue of the meaning code has to people vs. the meaning it has to the computer – a good topic for verbal discussion.

I would need to think about this more, and look into programming language research/operational semantics before engaging that conversation. However one thread of an answer would be Ed Finn’s concept of “effective procedure”, a procedure which is deemed worthwhile because it is valid both in computer terms and human terms (he takes the example of the netflix recommendation algorithm). In addition, I recently read this paper which advocates that Boole was able to develop his system of formal logic because he decided not to care about the why or the how: boolean logic only focuses on the validity of any procedure (how) and then leaves the interpretation to the humans. In this case, machine understanding and human understanding are absolutely separate. Perhaps another point of overlap between those two is that of data structures? They might represent a more direct (because they’re more simple?) mapping to human mental models than what algorithms are for human mental processes.

I think there is something higher-level than a specific programming language and lower-level than the abstract algorithm which is important to your discussion, and which you brush up against without directly confronting. That’s what is called paradigm or (in a conflict with your terminology) idiom: functional, imperative, object-oriented, etc. We can call Ruby Lisp-like or say that Python’s lambda is Lisp-like, but really Lisp itself is lambda-calculus-like, as are the lambda operators in these two languages. Choosing a recursive or iterative solution, using more functional or more imperative frameworks, is facilitated by many languages. This means that what is “good style” in ML depends not only on the specifics of ML, but whether you think functional or imperative programming is better, since ML supports both.

This is a very good point, and it bridges the aesthetics (form) and the poetics (content) of a program. This seems to be a good example of Kenneth Burke’s idea of terministic screens: the initial words of a text set the context and the frame (i.e. the screen) for the reader to appreciate “correctly” the text. Indeed seeing (deducing?) that a program is object-oriented or functional should have consequences on how one can judge and appreciate its aesthetic features. However, I’m struggling to see to what extent it can be said that certain paradigms have “aesthetics”. What I mean here is that aesthetics are manifested through the implementation of a concept. So perhaps, going one level up, paradigms have aesthetics in how they represent the broader (and common) field of computation/lambda calculus/turing completeness?

The connection to architecture is a great one. As I was reading the beginning of the paragraph, I was wondering if you were going there, and you were. Can you continue this and map your emerging understanding of code aesthetics into architectural aesthetics? Are the intentionally obfuscated productions of hackers similar in any way to sometimes uninhabitable but structural follies (see

I was particularly interested by a keynote that Christopher Alexander gave at the ACM OOPSIG a couple of decades ago, in which he presented his work on patterns as “patterns which support living”, and am now wondering to what extent beautiful code could be made up of “patterns which support thinking” (obviously, thinking implies “good and easy” thinking here, as I’m assuming Alexander means “good and easy life”).

Some of the other thoughts that I have a regard the relationship between architect and craftsman (even though the dawn of the architect foresees the demise of the craftsman?). Do physical architects only relate to software architects (designing the overall concept rather than figuring out the building blocks).

In terms of style, I can actually see some kind of correlation (similarly to alexander’s patterns above). Style can be seen in both as a form of social order, not in Foucault’s sense, but rather that a sylistic imperative in software connotes group cohesion, the same way that stylistic choices in architecture connote group cohesion as well.

Finally, in terms of mapping the groups I’ve identified of code practitioners, here’s a parallel that I can think of. Artists: building as statement, software as a statement (e.g. brandlhuber vs. I/O/D) Academics: sketches, concepts, ideas over realizations Hacker: I can’t seem to make a connection here, because hackers operate as underdogs, architects operate as overdogs, so to speak. i don’t know enough, but i would imagine things like louvre abu dhabi’s dome / mies van der rohe / starchitects who push boundaries of the possible? I would need to read up more on hackers and their practices before giving a further answer, though.

Details: Some claims are understated, some may need substantiation. “The vast majority of code written today has been done by software engineers” doesn’t seem like a controversial claim, but how exactly do you know? Lots of code has been written by students, researchers, hobbyists. When you describe code practitioners, you say “These categories include” … but you mean “These categories are …” And a very minor item: Beautiful Code, because it is an edited collection, can be called a book but is not a monograph.

Yes, these are all very good points. If the metric is the number of lines of codes, then we can safely assume that software developers are indeed the main contributors to code, if only just by taking Microsoft and Google products into account (I would also put open-source developers in that category, as they do ship “commercial” products). Source: