- [ ] add a footnote about Brenda : Brenda Baker undertook her Fortan-to-Ratfor converter against the advice of her department head–me. I thought it would likely produce an ad hoc reordering of the orginal, freed of statement numbers, but otherwise no more readable than a properly indented Fortran program. Brenda proved me wrong. She discovered that every Fortran program has a canonically structured form. Programmers preferred the canonicalized form to what they had originally written. source
chap 4 - programming
- case studies
- choose the case-studies in the way that is the most illustrative of my point. doesn’t have to be huge.
- i should definitely have a more comparative approach: multiple code-bases, with aesthetics which are tied to LANGUAGE, COMMUNITY and PROBLEM (question of the idiomatic). this is better than having one case study after another, completely discontinued.
- find similar problems in different programs, see how they deal with it
- find specific cases where the cognitive load is high
- again, DO IT IN PARALLEL as a comparative studies.
- in language design section, inckude iverson_notation_as_tool_for_thought, beardsley: cognitive gratification under ideal circumstances
emotions and functionality
Implied in the design of the Source Code Poetry competition is the idea that the writing of code is an artistic enterprise. Indeed, “real” programmers are the ones whose code itself is poetry in motion. The emphasis on executable code reveals aesthetic possibilities of programming languages that blend form and function. Such poems are fascinating because they are variably accessible and inaccessible to readers, a function of their readers’ knowledge of programming languages and facility with poetry. They also provide means of expression in multiple ways: the visual aesthetics of the code on the page, an aural dimension if read aloud, and the output rendered by the code when compiled. Their possibilities for interpretation, then, are fragmentary, requiring negotiation on these many fronts to appreciate and understand.
in the last section, 5.3
- [ ] functions need to be made clearer. there are three levels (1) syntactical/formal validity, (2) what the program down (operational semantics) and (3) what the program should do (intentional semantics). THIS SHOULD BE DISCUSSED AT THE BEGINNING RATHER THAN JUST THE LAME INTRO ON LAMBDA CALCULUS. then start from those to discuss the function/meaning of computer programs
- [ ] i talk about “syntactic meaning” but this makes no sense, meaning is only semantic
- [ ] again, shorten the code snippets and explain them
- [ ] re-quote hayles and her regime of computation (surface, depth, etc.) when i also talk about paloque berges et. al.
- [ ] add this quote from The Embodied Aesthetics of Code, quoted in Sy Brand: “an object is ‘functionally beautiful’ to the extent that its aesthetic properties contribute to its overall performance—the functional beauty of an object enhances its fulfilling its primary function” and, in this case, the primary function is not to be executed, but to be understood.
- [ ] from sy brand talk, gabrielle starr, feeling beauty: the neuroaesthetics of the experience: “Aesthetic response enables the comparison and integration of novel kinds of reward in a process that opens possibilities for new knowledge, or new ways of negotiating the world. The perceptions, images, and emotions we find through our experience of poetry, painting and music put ideas and events into relation with one another that would rarely, if ever, be possible outside the arts.”
chap 3 - beauty
overall, I should keep in mind that I do not have a technical audience, and I should rework/remove a lot of the examples, and add extensive discussions and rationale as to why those examples are there
- mention that knowledge influences how we perceive things (brandy, mathematical beauty)
- In literature, include rousset: forme et signification
- remove god and xml example?
- add more code examples (check the architecture of open source applications? redis?)
- mathematics: add a discussion of dijkstra’s shortest path algorithm?
- add knuth on dijkstra, simple program, complex proof (knuth, simple, 1990)
chap 2 - understanding
- [ ] recs from guido, neuropsychologists who might be interested: stanislas dehaene and christophe paillier
- [ ] levels of software (as we may code) highlights the need for such a thing (quoting: What if, instead of lowering source code down for the purpose of execution, we raised source code for the purpose of understanding?)
- [ ] tools add to means of understanding and IDEs deciding how we write: https://thorstenball.com/blog/2020/02/04/how-much-do-we-bend-to-the-will-of-our-tools/
- [ ] tools including a discussion of how does step in a debugger relate to code as terrain, or surface coverage for tests? e.g. how does build and architecture related to code as structure?
- [ ] programmer metaphors my approach to metaphors should be more systematic: that is, I should look into how metaphors can represent a SYSTEM (for instance,
symlink is a limitation when it comes to the files and folder metaphor)
- [ ] programmer metaphors metaphor of the
macro (implies scale), of
global, implies scale as well.
libraries is also a metaphor that is literary.
- [ ] programmer metaphors refer to master/slave as a problematic one
chap 1 - ideals
- explain that beauty might be a metaphor itself of “good” (value judgments, etc.)