finished 5.1

periode · Aug 4, 2023 · 0d943dd · 0d943dd
1 parent 4aee1f5
commit 0d943dd
Show file tree

Hide file tree

Showing 14 changed files with 409 additions and 131 deletions.
diff --git a/docs/2023-8-4-162/redaction/todo.html b/docs/2023-8-4-162/redaction/todo.html
@@ -0,0 +1,131 @@
+
+	<!DOCTYPE html>
+	<html>
+		<head>
+			<meta charset="utf-8"/>
+			<title>works in public</title>
+			<link rel="stylesheet" href="/style.css"/>
+		</head>
+		<body>
+			<div class="way">
+				<a href="/index.html">cover</a>
+			</div>
+			<div class="holding tight">
+				<h1 id="todo">todo</h1>
+
+<h2 id="format">format</h2>
+
+<ul>
+  <li>[ ] deal with frames and page breaks on minted; <a href="https://tex.stackexchange.com/questions/433192/breaking-pages-in-minted-package">https://tex.stackexchange.com/questions/433192/breaking-pages-in-minted-package</a></li>
+  <li>deal with inline quotes properly (using the <code>dirtytalk</code> package)</li>
+  <li>harmonize spacers</li>
+  <li>add index</li>
+  <li>harmonize spacer and spacersmall</li>
+</ul>
+
+<h2 id="conclusion">conclusion</h2>
+
+<ul>
+  <li>[ ] 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. <a href="https://web.archive.org/web/20200315093052/https://minnie.tuhs.org/pipermail/tuhs/2020-March/020664.html">source</a></li>
+</ul>
+
+<h2 id="chap-4---programming">chap 4 - programming</h2>
+
+<ul>
+  <li>
+    <p>rewrite intro of chap once the whole thing is re-read</p>
+  </li>
+  <li>
+    <p><strong>case studies</strong></p>
+    <ul>
+      <li>choose the case-studies in the way that is the most illustrative of my point. doesn’t have to be huge.</li>
+      <li>i should definitely have a more comparative approach: multiple code-bases, with aesthetics which are tied to <strong>LANGUAGE</strong>, <strong>COMMUNITY</strong> and <strong>PROBLEM</strong> (question of the idiomatic). this is better than having one case study after another, completely discontinued.</li>
+      <li>find similar problems in different programs, see how they deal with it</li>
+      <li>find specific cases where the cognitive load is high</li>
+      <li>again, <strong>DO IT IN PARALLEL</strong> as a comparative studies.</li>
+    </ul>
+  </li>
+</ul>
+
+<h3 id="programming-languages">programming languages</h3>
+
+<h3 id="styles">styles</h3>
+
+<ul>
+  <li>[ ] language design \url{http://rigaux.org/language-study/syntax-across-languages/}</li>
+  <li>
+    <p>[ ] add marielle macé to a bit of conclusion on the styles of programmers</p>
+  </li>
+  <li>for fig. 62 (self_inspect), step through a computer interpretation of the process, before giving a literary interpretation of the process.</li>
+  <li>for the code poems, I need to be able to articulate their relevance when looking at different domains. they’re not just related to literature, but also architecture (follies, pavillions) or math (pure math), while other source code (linux kernel) might also be a sort of literature (legal code). but also make it explicit that i talk about the ones that can run, not the code poems that are not executable</li>
+  <li>in the case of list comprehension in Python, it is both a technical and social environment</li>
+</ul>
+
+<h3 id="functions">functions</h3>
+
+<ul>
+  <li>[ ] rather than having 5.3 as this total disconnect, maybe start by writing a monolith to avoid the pitfalls of structure. particularly because at this point i need to synthesize. rather work on <em>connections and disconnections</em> between the social and the functional?</li>
+  <li>[ ] re-quote hayles and her regime of computation (surface, depth, etc.) when i also talk about paloque berges et. al.</li>
+</ul>
+
+<h2 id="chap-3---beauty">chap 3 - beauty</h2>
+
+<h3 id="aesthetics">aesthetics</h3>
+
+<ul>
+  <li>mention that knowledge influences how we perceive things (brandy, mathematical beauty)</li>
+  <li>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.”</li>
+</ul>
+
+<h3 id="literature">literature</h3>
+
+<ul>
+  <li>In literature, include rousset: forme et signification</li>
+  <li>remove god and xml example?</li>
+</ul>
+
+<h3 id="architecture">architecture</h3>
+
+<ul>
+  <li>add more code examples (check the architecture of open source applications? redis?)</li>
+</ul>
+
+<h3 id="mathematics">mathematics</h3>
+
+<ul>
+  <li>mathematics: add a discussion of dijkstra’s shortest path algorithm?</li>
+  <li>add knuth on dijkstra, simple program, complex proof (knuth, simple, 1990)</li>
+</ul>
+
+<h2 id="chap-2---understanding">chap 2 - understanding</h2>
+
+<ul>
+  <li>[ ] recs from guido, neuropsychologists who might be interested: stanislas dehaene and christophe paillier</li>
+  <li>[ ] <strong>levels of software</strong> (<a href="https://nshipster.com/as-we-may-code/">as we may code</a>) 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?)</li>
+  <li>[ ] <strong>tools</strong> add to means of understanding and IDEs deciding how we write: <a href="https://thorstenball.com/blog/2020/02/04/how-much-do-we-bend-to-the-will-of-our-tools/">https://thorstenball.com/blog/2020/02/04/how-much-do-we-bend-to-the-will-of-our-tools/</a></li>
+  <li>[ ] <strong>tools</strong> 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?</li>
+  <li>[ ] include the concept of interface by matthew kirschenbaum <a href="https://www.researchgate.net/profile/Nancy-Ide/publication/229666751_Preparation_and_Analysis_of_Linguistic_Corpora/links/5a75ec770f7e9b41dbd04d97/Preparation-and-Analysis-of-Linguistic-Corpora.pdf#page=550">https://www.researchgate.net/profile/Nancy-Ide/publication/229666751_Preparation_and_Analysis_of_Linguistic_Corpora/links/5a75ec770f7e9b41dbd04d97/Preparation-and-Analysis-of-Linguistic-Corpora.pdf#page=550</a></li>
+  <li>[ ] <strong>programmer metaphors</strong> my approach to metaphors should be more systematic: that is, I should look into how metaphors can represent a SYSTEM (for instance, <code>symlink</code> is a limitation when it comes to the files and folder metaphor)</li>
+  <li>[ ] <strong>programmer metaphors</strong> metaphor of the <code>macro</code> (implies scale), of <code>scope</code>, of <code>global</code>, implies scale as well. <code>libraries</code> is also a metaphor that is literary.</li>
+  <li>[ ] <strong>programmer metaphors</strong> refer to master/slave as a problematic one</li>
+</ul>
+
+<h2 id="chap-1---ideals">chap 1 - ideals</h2>
+
+<ul>
+  <li>[ ]  add a subsubsec on verbosity?</li>
+  <li>
+    <p>[ ] harmonize subsubsection (Smells -&gt; smelly?)</p>
+  </li>
+  <li>[ ] add <a href="../readings/notes/pressman_software_engineering_practicioners_approach.md">pressman - software engineering: a practicioner’s approach</a> in the part about software developers</li>
+</ul>
+
+<h2 id="introduction">introduction</h2>
+
+<ul>
+  <li>explain that beauty might be a metaphor itself of “good” (value judgments, etc.)</li>
+</ul>
+
+			</div>
+		</body>
+	</html>
diff --git a/docs/index.html b/docs/index.html
@@ -31,6 +31,14 @@ <h1>the role of aesthetics in the understandings of source code</h1>
 
 
 
+							<h2> 2023 - 8 - 4 </h2>
+
+								<h3> 162 </h3>
+
+									<li><a href="2023-8-4-162/redaction/todo.html">redaction/todo.html</a></li>
+
+
+
 							<h2> 2023 - 8 - 2 </h2>
 
 								<h3> 2056 </h3>

diff --git a/redaction/corpus/error_handling.go b/redaction/corpus/error_handling.go
diff --git a/redaction/corpus/iterating.c b/redaction/corpus/iterating.c
@@ -0,0 +1,12 @@
+#include <stdio.h>
+
+int main()
+{
+    int max_count = 5;
+    struct int my_list[max_count] = {2046, 2047, 2048, 2049, 2050};
+
+    for (int i = 0; i < max_count; i++)
+    {
+        printf("%d", my_list[i]);
+    }
+}
diff --git a/redaction/corpus/iterating.py b/redaction/corpus/iterating.py
@@ -0,0 +1,4 @@
+my_list = [2046, 2047, 2048, 2049, 2050]
+
+for item  in my_list:
+    print(item)
diff --git a/redaction/corpus/multiple_returns.go b/redaction/corpus/multiple_returns.go
@@ -0,0 +1,9 @@
+package main
+
+func getNumbers() (int, float64, int) {
+	return 1, 2.0, 3
+}
+
+func main() {
+	first, _, third := getNumbers()
+}
diff --git a/redaction/corpus/multiple_returns.js b/redaction/corpus/multiple_returns.js
@@ -0,0 +1,8 @@
+let getNumbers = () => {
+    return [1, 2.0, 3]
+}
+
+
+numbers = getNumbers()
+first = numbers[0]
+second = numbers[2]
diff --git a/redaction/corpus/non-thread.go b/redaction/corpus/non-thread.go
@@ -0,0 +1,20 @@
+package main
+
+import (
+	"fmt"
+	"math/rand"
+	"time"
+)
+
+func recall(date int) {
+	random_delay := (rand.Int() % 5) + 1
+	time.Sleep(time.Second * time.Duration(random_delay))
+	fmt.Println(date)
+}
+
+func main() {
+	recall(2045)
+	recall(2046)
+
+	fmt.Println("We're done!")
+}
diff --git a/redaction/corpus/thread.c b/redaction/corpus/thread.c
@@ -1,16 +1,23 @@
 #include <iostream>
 #include <thread>
+#include <pthread>
+#include <unistd>
 
 void recall(int date)
 {
-    std::cout << date << '\n';
+    r = (rand() % 5) + 1 sleep(r)
+     std::cout << date << '\n';
 }
 
 int main()
 {
-    std::thread thread(recall, 2046);
+    pthread_t thread1;
+    pthread_t thread2;
+    pthread_create(&thread1, NULL, recall, 2045);
+    pthread_create(&thread2, NULL, recall, 2046);
 
-    thread.join();
+    pthread_join(thread1, NULL);
+    pthread_join(thread2, NULL);
 
     cout << "We're done!";
 

diff --git a/redaction/corpus/thread.go b/redaction/corpus/thread.go
@@ -2,13 +2,19 @@ package main
 
 import (
 	"fmt"
+	"math/rand"
+	"time"
 )
 
 func recall(date int) {
+	random_delay := (rand.Int() % 5) + 1
+	time.Sleep(time.Second * time.Duration(random_delay))
 	fmt.Println(date)
 }
+
 func main() {
 	go recall(2046)
+	go recall(2047)
 
 	fmt.Println("We're done!")
 }
diff --git a/redaction/introduction.tex b/redaction/introduction.tex
@@ -67,7 +67,7 @@ \subsection{Beautiful code}
 
 Considered one of the most canonical textbooks in the field, \emph{The Art of Computer Programming} highlights two important aspects of programming for our purpose: that it can be an aesthetic experience and that it is the result of a craft, rather than of a highly-formalized systematic process, as we will see in \ref{subsubsec:crafting-software}.
 
-Craftsmanship is an essentially fleeting phenomenon, a practice rather than a theory, in the vein of Michel De Certeau's \textit{tactics}, bottom-up actions informally designed and implemented by the users of a situation, product or technology as opposed to \textit{strategies} \citep{certeau_invention_1990}, in which ways of doing are deliberately prescribed in a top-down fashion. Craft is hard to formalize, and the development of expertise in the field happens more often through practice thanthrough formal education \citep{sennett_craftsman_2009}. It is also one in which function and beauty exist in an intricate, embodied and implicit relationship, based on subjective qualitative standards and functional purposes rather than strictly quantitative measurements \citep{pye_nature_2008}. Approaching programming as a craft has been a recurrent perspective \citep{levy_programmation_1992,dijkstra_craftsman_1982}, and connects to the multiple testimonies of encountering beautiful code, some of which have made their ways into edited volumes or monographs \citep{oram_beautiful_2007,chandra_geek_2014,gabriel_patterns_1998}.
+Craftsmanship is an essentially fleeting phenomenon, a practice rather than a theory, in the vein of Michel De Certeau's \textit{tactics}, bottom-up actions informally designed and implemented by the users of a situation, product or technology as opposed to \textit{strategies} \citep{certeau_invention_1990}, in which ways of doing are deliberately prescribed in a top-down fashion. Craft is hard to formalize, and the development of expertise in the field happens more often through practice than through formal education \citep{sennett_craftsman_2009}. It is also one in which function and beauty exist in an intricate, embodied and implicit relationship, based on subjective qualitative standards and functional purposes rather than strictly quantitative measurements \citep{pye_nature_2008}. Approaching programming as a craft has been a recurrent perspective \citep{levy_programmation_1992,dijkstra_craftsman_1982}, and connects to the multiple testimonies of encountering beautiful code, some of which have made their ways into edited volumes or monographs \citep{oram_beautiful_2007,chandra_geek_2014,gabriel_patterns_1998}.
 
 Additionally, informal exchanges among programmers on forums, mailing lists, blog posts and code repositories often mention beautiful code, either as a central discussion point or simply in passing. These testimonies constitute the first part of our corpus, as sources in which programmers comment on the aesthetic dimension of their practice. The second part of the corpus is composed of selected program texts, which we will examine in order to identify and formalize which aspects of the textual manifestation of software can elicit an aesthetic experience.