diff --git a/docs/2023-8-1-208/redaction/todo.html b/docs/2023-8-1-208/redaction/todo.html new file mode 100644 index 0000000..2213292 --- /dev/null +++ b/docs/2023-8-1-208/redaction/todo.html @@ -0,0 +1,162 @@ + + + + + + works in public + + + +
+ cover +
+
+

todo

+ +

format

+ + + +

conclusion

+ + + +

chap 4 - programming

+ + + +

programming languages

+ + + +

styles

+ + + +

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

+ + + +

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

+ +

aesthetics

+ + + +

literature

+ + + +

architecture

+ + + +

mathematics

+ + + +

chap 2 - understanding

+ + + +

chap 1 - ideals

+ + + +

introduction

+ +

done

+ +

general

+ + + +
+ + diff --git a/docs/index.html b/docs/index.html index 57c4ce1..166de7e 100644 --- a/docs/index.html +++ b/docs/index.html @@ -31,6 +31,16 @@

the role of aesthetics in the understandings of source code

+

2023 - 8 - 1

+ +

208

+ +
  • redaction/todo.html
    • + + + + +

    2023 - 7 - 31

    2250

    diff --git a/docs/thesis.pdf b/docs/thesis.pdf index e63cd12..cdcb263 100644 Binary files a/docs/thesis.pdf and b/docs/thesis.pdf differ diff --git a/redaction/beauty.tex b/redaction/beauty.tex index 8330c47..7c4505c 100644 --- a/redaction/beauty.tex +++ b/redaction/beauty.tex @@ -271,7 +271,7 @@ \subsection{Words in space} The second reference is primarily temporal. The keyword \lstinline{defer} in the line \lstinline{defer timer.Stop()} specifically marks the deferred execution of this particular function to the specific moment at which the current function (\lstinline{Shutdown()}) returns. This reference is not absolute (as is the timer on the line above, even though it might not be determinate), but rather relative, itself dependent on when the current function will return. Here, the programming language itself makes it simple to express this relative temporal operation. -Finally, we can take a look at both the last \lstinline{select\{ ... \}} statement of the function to see a more complex interplay of both space and time. There are two things happening there. With the specific \lstinline{<-} arrow, the pictorial representation shows how a message is incoming, either from \lstinline{ctx.Done()}, which itself comes from outside the current function, given as an argument, or from \lstinline{timer.C}, which comes from the timer that has just been declared in the current function. Both of these messages come from different places, one very distant, and the other very local, and might arrive at different moments. Here, the \lstinline{<-} denotes the movement of an incoming message, expliciting where the messages come from, and in which order they should be treated, and thus facilitates the handling of event with varying spatio-temporal properties. +Finally, we can take a look at both the last \lstinline{select} statement of the function to see a more complex interplay of both space and time. There are two things happening there. With the specific \lstinline{<-} arrow, the pictorial representation shows how a message is incoming, either from \lstinline{ctx.Done()}, which itself comes from outside the current function, given as an argument, or from \lstinline{timer.C}, which comes from the timer that has just been declared in the current function. Both of these messages come from different places, one very distant, and the other very local, and might arrive at different moments. Here, the \lstinline{<-} denotes the movement of an incoming message, expliciting where the messages come from, and in which order they should be treated, and thus facilitates the handling of event with varying spatio-temporal properties. The listing \ref{code:shutdown} shows not only different spaces of executions, nor only different moments of execution, but very much the intertwining of space and time. One of the earlier approaches to the specific tokens which represent space in the traditional novel has also related it to time: the chronotope is described by Mikhail Bakhtin as the tight entanglement of temporal and spatial relationships that are artistically expressed in literature. Those markers execute a double function, as they allow for the reification of temporal events and spatial settings during the unfolding of narrative events\footnote{"\emph{Time, as it were, thickens, takes on flesh, becomes artistically visible; likewise, space becomes charged and responsive to the movements of time, plot and history.}" \citep{bakhtin_dialogic_1981}}. @@ -288,28 +288,28 @@ \subsection{Words in space} \section{Architecture and understanding} \label{sec:arch-understanding} -At its most common denominator, architecture is then concerned with the gross structure of a system. At its best, architecture can support the understanding of a system by addressing the same problem as cognitive mapping does: simplifying our ability to grasp large system. This phrase appears in Kevin Lynch's work on \emph{The Image of the City}, in which he highlighted that our understanding of an urban environment relies on combinations of patterns (node, edge, area, limit, landmark) to which personal, imagined identities are ascribed. The process is once again that of abstraction, but goes beyond that, and includes a subjective perspective \citep{lynch_image_1959}. Moving from the urban planner's perspective to the architects, we see how each individual component contributes to the overall legibility of the system. This section considers how individual structures, through their assessed beauty, offer a cognitive involvement to their participants. +At its most common denominator, architecture is concerned with the gross structure of a system. At its best, architecture can support the understanding of a system by addressing the same problem as cognitive mapping does: simplifying our ability to grasp large system. This phrase appears in Kevin Lynch's work on \emph{The Image of the City}, in which he highlighted that our understanding of an urban environment relies on combinations of patterns (node, edge, area, limit, landmark) to which personal, imagined identities are ascribed. The process is once again that of abstraction, but goes beyond that, and includes a subjective perspective \citep{lynch_image_1959}. Moving from the urban planner's perspective to the architects, we see how each individual component contributes to the overall legibility of the system. This section considers how individual structures, through their assessed beauty, offer a cognitive involvement to their participants. -Beauty in architecture is one of the discipline's fundamental components, dating back to Vitruvius's maxim that a building should exhibit \emph{firmitas, utilitas, venustas}—solidity, usefulness, beauty. And yet in practice, beauty, or the abillity to elicit an aesthetic experience, is not sufficient, and sometimes not even required, for a building to be considered architectural. Even though architecture is usually considered as an art, it is nonetheless also a product of engineering, and thus a hybrid field, one where function and publicness modulate what could be otherwise a "pure" aesthetic judgment. +Beauty in architecture is one of the discipline's fundamental components, dating back to Vitruvius's maxim that a building should exhibit \emph{firmitas, utilitas, venustas}—solidity, usefulness, beauty. And yet in practice, beauty, or the abillity to elicit an aesthetic experience, is not sufficient, and sometimes not even required, for a building to be considered architectural. Even though architecture is usually considered as an art, it is also a product of engineering, and thus a hybrid field, one where function and publicness modulate what could be otherwise a "pure" aesthetic judgment. -This sections looks at architecture through its multiple aspects, to highlight to which extent some of these are reflected in source code\footnote{Recall how, in \ref{subsubsec:crafting-software}, programmers tended to refer extensively to themselves as architects.}. Through an investigation of the tensions and overlaps of form, function, context and materiality in the built space, we identify similarities in the programmed space. +This sections looks at architecture through its multiple aspects, to highlight to which extent some of these are reflected in source code\footnote{Recall how, in \ref{subsubsec:crafting-software}, programmers tended to refer extensively to themselves as architects, engineers or craftspeople.}. Through an investigation of the tensions and overlaps of form, function, context and materiality in the built space, we identify similarities in the programmed space. Particularly, we will look at how an understanding of patterns translates across both domains, in response to both architecture and programming's material constraints, due to the physical instantiation of buildings and programs in a situated context. \subsection{Form and Function} \label{subsec:form-function} Particularly, our interest here is with the cognitive involvement in the architectural work. What is there to be understood in a building, and how do buildings make it intelligible? The early theoretical answers to this question is to be found in the work of Italian architects, such as Andrea Palladio, whose conception of its discipline came from ideal platonic form, and mathematical relation between facade and inner elements, as well as Leon Battista Alberti, whose consideration of beauty in architecture, as such an organization of parts that nothing can be changed without detriment to the whole \citep{scruton_aesthetics_2013}\footnote{Such a definition is a reminiscent of how Vladimir Nabokov defines beauty in literature: "\emph{A really good sentence in prose should be like a good line in poetry, something you cannot change, and just as rhythmic and sonorous}" \citep{nabokov_lectures_1980}}. -While structure is meant to stand the test of time and natural forces\footnote{A purposes exemplified by the still standing structures of Roman and Greek antiquities, resulting from a particular mixing process of concrete.}, utility can be assessed by the extent to which a building fulfills its intended function. How the beauty of a building relates to its function, whether it can be completely dissociated from it, or if it is dependent on the fulfillment of its function, is still a matter of debate between formalists and functionalists. Nonetheless, the position we take here is in line with Parsons and Carlson, in that fitness of an object is a core component of how it is appreciated aesthetically \citep{parsons_functional_2012}, and that form is hardly separable from function. +While structure is meant to stand the test of time and natural forces\footnote{A purpose exemplified by the still standing structures of Roman and Greek antiquities, resulting from a particular mixing process of concrete.}, utility can be assessed by the extent to which a building fulfills its intended function. How the beauty of a building relates to its function, whether it can be completely dissociated from it, or if it is dependent on the fulfillment of its function, is still a matter of debate between formalists and functionalists. Nonetheless, the position we take here is in line with Parsons and Carlson, in that fitness of an object is a core component of how it is appreciated aesthetically \citep{parsons_functional_2012}, and that form is hardly separable from function. -Furthermore, Roger Scruton, in his philosophical investigation of architecture, brings up the question of language—if buildings are to be cognitively engaged with, then one should be able to grasp what they communicate, what they stand for, what they express. To do so, one can turn to the fact that architectural works are often composed of interconnected, coherent sub-parts, which then contribute to the whole, in a form of \emph{gestaltung}. +In some way, then, form should be able to communicate the function of a building. Roger Scruton, in his philosophical investigation of architecture, brings up the question of language—if buildings are to be cognitively engaged with, then one should be able to grasp what they communicate, what they stand for, what they express. To do so, he starts from the fact that architectural works are often composed of interconnected, coherent sub-parts, which then contribute to the whole, in a form of \emph{gestaltung}. \begin{quote} Architecture seems, in fact, to display a kind of 'syntax': the parts of a building seem to be fitted together in such a way that the meaningfulness of the whole will reflect and depend upon the manner of combination of its parts. \citep{scruton_aesthetics_2013} \end{quote} -Yet, he develops an argumentation which, against Goodman, suggests that architecture is not so much articulated as a language, than as a set of conventions and rules, and that it is not a representative medium (which would imply valid and invalid syntax, as well as intent), but rather an expressive one. Architectural significance, then, relies on the presence and arrangement of those evolving conventions—that is, a style—rather than on the depiction of a subject through an exact syntax. +Yet, he develops an argumentation which suggests that architecture is not so much articulated as a language, than as a set of conventions and rules, and that it is not a representative medium (which would imply valid and invalid syntax, as well as intent), but rather an expressive one. Architectural significance, then, relies on the presence and arrangement of those evolving conventions—that is, a style—rather than on the depiction of a subject through an exact syntax. While architecture might not represent content the same way literature does, it is nonetheless expressive, and relies on particular styles—recurring formal patterns and ways of doing—to express a tone, a feeling, or a \emph{stimmung} in their dwellers. -While architecture might not represent a subject matter the same way literature does, it is nonetheless expressive, and relies on particular styles (recurring formal patterns) to express a tone, a feeling, or a \emph{stimmung} in their dwellers. As identified in \ref{subsec:beauty-architecture}, the similarities between software and architecture can be mapped as symmetrical approaches: as top-down or bottom-up. Modernism, and the conventions that make up this architectural thought, are the top-down result of the intersection of function, form and industry. +As identified in \ref{subsec:beauty-architecture}, the similarities between software and architecture can be mapped as symmetrical approaches: as top-down or bottom-up, from an architect's perspective, or from a craftperson's. Since we focus on what a building expresses, we need to consider the source of such an expression. First, we look at how modernism, and the conventions that make up this architectural thought, are the top-down result of the intersection of function, form and industry, and reveal the influence of functional design on the aesthetic appreciation of a work. The central modern architectural standard is Louis Sullivan's maxim that \emph{form follows function}, devised as he was constructing the early office buildings in North America. Sullivan's statement is thus that what the building enables its inhabitants to do, inevitably translates into concrete, visible, and sensual consequences. @@ -319,7 +319,9 @@ \subsection{Form and Function} It is the pervading law of all things organic and inorganic, of all things physical and metaphysical, of all things human and all things superhuman, of all true manifestations of the head, of the heart, of the soul, that the life is recognizable in its expression, that form ever follows function. This is the law. \citep{sullivan_tall_1896} \end{quote} -The value of the building is therefore derived from what it allows the individuals to do: the office building allows them to work, the school to learn, the church to pray and the house to live. To do so, modernist architecture rejects any superfluous decoration, or extraneous addition, as a corruption of the purity of the building's function. In a similar vein, Le Corbusier, another fundamental actor of modern architecture, equates the building with its function, advocating for the suppression of decorative clutter and unnecessary furnishings and possessions, and hailing transparency and simplicity as architectural virtues \citep{lecorbusier_vers_1923}, and culminating in Le Corbusier's assessment that the architectural plan as a generator, and the house as a machine to be lived in. Indeed, architectural works are a kind of system, in that they constitute sets of interrelated structural components, where the parts are connected by distinctive structural and behavioral relations; and yet the set of conventions to which Le Corbusier contributes is an abstract representation of this systemic nature. He focuses on the plan as the primary source of architectural quality\footnote{For software developers, the equivalent of an architectural plan would be a modelling system such as UML: a language to describe structural relationships between software components, with an example shown in \ref{graphic:uml}.} +The value of the building is therefore derived from what it allows the individuals to do: the office building allows them to work, the school to learn, the church to pray and the house to live. To do so, modernist architecture rejects any superfluous decoration, or extraneous addition, as a corruption of the purity of the building's function. In a similar vein, Le Corbusier, another fundamental actor of modern architecture, equates the building with its function, advocating for the suppression of decorative clutter and unnecessary furnishings and possessions, and hailing transparency and simplicity as architectural virtues \citep{lecorbusier_vers_1923}, and culminating in Le Corbusier's assessment that the architectural plan as a generator, and the house as a machine to be lived in. + +From this perspective, architectural works are a kind of system, in that they constitute sets of interrelated structural components, where the parts are connected by distinctive structural and behavioral relations; and yet the set of conventions to which Le Corbusier contributes is an abstract representation of this systemic nature. He focuses on the plan as the primary source of architectural quality. For software developers, the equivalent of an architectural plan would be a modelling system such as UML: a language to describe structural relationships between software components, with an example shown in \ref{graphic:uml}. From a modernist angle, the aesthetic value of a building is thus directly dependent on how well it performs an abstractly defined function for its users, assessed at a structural level. \begin{figure} \includegraphics[width=0.8\textwidth,height=\textheight,keepaspectratio,center]{Policy_Admin_Component_Diagram.png} @@ -327,36 +329,48 @@ \subsection{Form and Function} \label{graphic:uml} \end{figure} -It is clear the modernists thought of function as engineering function, and aligned it with engineering aesthetics\footnote{\emph{Esthétique de l'ingénieur} is the title of one of the chapters of Le Corbusier's manifesto, \emph{Vers une Architecture} \citep{lecorbusier_vers_1923}}. Nonetheless, such a conception of function is definitely machinic, thinking of airflow, heat exchange or drainage, expressing a particular feeling of progress and achievement through industrial manufacturing techniques allowing for new material capabilities against contextual understandings. +Just as a two-dimensional floorplan and a three-dimensional building are different, a diagram and a program text are also different. This difference is highlighted throught the process of construction in architecture, and implementation in software development, involving respectively engineers and programmers to realize the work that has been designed by the architect. + +It is clear the modernists thought of function as engineering function, and aligned it with engineering aesthetics\footnote{\emph{Esthétique de l'ingénieur} is the title of one of the chapters of Le Corbusier's manifesto, \emph{Vers une Architecture} \citep{lecorbusier_vers_1923}}. Nonetheless, such a conception of function is definitely machinic, consisting of airflow, heat exchange or drainage, expressing a particular feeling of progress and achievement through industrial manufacturing techniques allowing for new material capabilities against contextual understandings. Here again, the human is but a small part in a dynamic system. Jacques Rancière, in his study of the Werkbund and the Bauhaus-inspired architecture, offers an alternative approach, away from the strcit functionality laid out by Sullivan and Le Corbusier before him. The simplification of forms and processes, he writes of the AEG Turbinenhalle in Berlin, which is normally associated with the reign of the machine, finds itself, on the contrary, related to art, the only thing able to spiritualize industrial work and common life \citep{ranciere_aisthesis_2013}. -Rancière offers us an additional perspective, departing form the strict function of an object or of a building, to its \emph{use}. Such a shift moves from a structure-centric perspective (such as Le Corbusier's ideal dimensions), to a human-centric perspective (such as Lacaton \& Vassal's practical extension of space and light). Peter Downton reiterates this point, when he states that "\emph{buildings and design are often judged from artistic perspectives that bear no relation to how the building’s occupants perceive or occupy the building.}" \citep{downton_knowledge_1998}. Indeed, architecture as an artform provides an immersive and systemic physical environment, thus shapes human psychology and agency within it, and forces the dweller to acknowledge and engage with their environment. This suggests that, from a formal, top-down approach which considers architecture as possessing a formal language to be realized exactly, there exists a complementary, bottom-up approach, centered around human construction and function. +By paying attention to the role of a detail, and of the human subjectivity and situatedness of the people inhabiting the building, departs form the strict function of an object or of a building, to its actual use. Such a shift moves the aesthetic judgment from a structure-centric perspective (such as Le Corbusier's ideal dimensions), to a human-centric perspective (such as Lacaton \& Vassal's practical extension of space and light). Peter Downton reiterates this point, when he states that "\emph{buildings and design are often judged from artistic perspectives that bear no relation to how the building’s occupants perceive or occupy the building.}" \citep{downton_knowledge_1998}; his conception of the artistic here, is one that aligns with Kant's definition of a work that is purposive in itself, and not based on a function that it should fulfill. + +One can see a translation of such a self-referential conception of art in the class of building which encompass follies and pavillions. These kinds of buildings are constructed first and foremost for their decorative properties, and only secondarily for its structural and functional properties. Follies, for instance, are individual buildings built on the demand of one specific individual's desire. They aim to represent something else than what they are, with no other purpose than ornament and the display of wealth. Pavilions, in the modern acceptation of the term, are rather displays of architectural and engineer prowess, demonstrating the use of new techniques and materials. By focusing only on design and technical feat, it is this prowess itself that is being represented: the function of the building is only to represent the skill of its builders. For instance, Junya Ishigami's pavillion at the Venice Biennale in 2008, shown in \ref{graphic:pavillion} consisted in a very elegant and aerial structure, but whose function was depending on the fact that no living being interacted with it\footnote{Indeed, the structure collapsed due to a cat's playfulness: "\emph{The Barbican says that the 37-year-old Ishigami is "internationally acclaimed", and there is certainly a buzz and fascination around him. Last year he won the Golden Lion, the highest prize at the Venice Architecture Biennale, for a structure that collapsed almost as soon as it was built, following an accident with a cat. Little was left but a scrawled note saying "Scusate, si è rotto. I'm sorry It's broken." } \citep{moore_junya_2011}"}. -% robert venturi for the learning from las vegas, but also contradiction and complexity +\begin{figure} + \includegraphics[width=0.8\textwidth,height=\textheight,keepaspectratio,center]{ishigami.jpg} + \caption{Pavillion built by Junya Ishigami + associates, showing a focus on appearance and structural feat, rather than habitability. Picture courtesy of Iwan Baan, 2008.} + \label{graphic:pavillion} +\end{figure} + +As an artform, architecture provides an immersive and systemic physical environment, and thus shapes human psychology and agency within it, in turn forcing the dweller to acknowledge and engage with their environment. This suggests that, from a formal, top-down approach which considers architecture as possessing a systematic language to be realized exactly at a structural level, there exists a complementary, bottom-up approach, centered around human construction and function. \subsection{Patterns and structures} \label{subsec:patterns-structures} -A counterpoint to this modernist approach of master planning is that of Christopher Alexander. Along with other city planners in the United States, such as William H. Whythe or Jane Jacobs, Alexander belongs to an empirical tradition of determining what makes a space \emph{good} or not, by examining its uses and the feelings it elicits in the people who tread its grounds. He elaborates an approach to architecture which does not exclusively rely on abstract design and technological efficiency, but rather takes into account the multiple layers and factors that go into making +A counterpoint to this modernist approach of master planning is that of Christopher Alexander. Along with other city planners in the United States, such as William H. Whythe or Jane Jacobs, Alexander belongs to an empirical tradition of determining what makes a built environment \emph{good} or not, by examining its uses and the feelings it elicits in the people who tread its grounds. He elaborates an approach to architecture which does not exclusively rely on abstract design and technological efficiency, but rather takes into account the multiple layers and factors that go into making \begin{quote} [...] beautiful places, places where you feel yourself, places where you feel alive \citep{alexander_timeless_1979} [...] \end{quote} -In \emph{The Timeless Way of Building}, he focuses on how beauty is involved in moving from disorganized to organized complexity, an design process which is not, in itself, the essence of beauty, but rather the condition for such beauty to arise. Alexander's conception of beauty, while very present throughout his work, is however not immediately concerned with the specifics of aesthetics, but rather with the existence of such objects. This existence, in turn, does require to be experienced sensually, including visually. +In \emph{The Timeless Way of Building}, he focuses on how beauty is involved in moving from disorganized to organized complexity, a design process which is not, in itself, the essence of beauty, but rather the condition for such beauty to arise. Alexander's conception of beauty, while very present throughout his work, is however not immediately concerned with the specifics of aesthetics, but rather with the existence of such objects. This existence, in turn, does require to be experienced sensually, including visually. In this process of achieving organized complexity, he highlights the paradoxical interplay between symmetry and asymmetry, and pinpoints beauty as the "deep interlock and ambiguity" of the two, a beauty he also finds the the relationship between static structures of the built environment, and the flow of living individuals in their midst. In his perspective, then, architecture should take into account the role of tension between opposite elements, rather than the combination of rational and abstract design elements. Such an approach echoes other considerations of tension as a source for stimulating human engagement,such as Ricoeur's analysis of the metaphor (see \ref{subsec:literary-metaphors}), and the resolution of the riddles presented in works of obfuscated source code (see \ref{subsec:hackers}). -He therefore considers aesthetic property as a consequence of qualities such as appropriateness, rightness to fit, not-simplicit and wholeness. All of these have in common the subsequent need for a purpose, a purpose which he calls the \emph{Quality Without a Name} \citep{alexander_timeless_1979}. This quality, he says, is semantically elusive, but nonetheless exists; it is, ultimately, the quality which sustains life, a conclusion which he reached after extensive empirical research: no one can name it precisely, but everyone knows what it refers to. It is the quality which makes one feel at home, which makes one feel like things make sense in a deep, unexplicable way. This reluctance to being linguistically explicited is echoed in the work of the craftsman, where a practitioner often finds herself showing rather than telling \citep{pye_nature_2008}, another domain with which software developers identify, explicited in \ref{subsubsec:crafting-software}. +He therefore considers a possible aesthetic experience as a consequence of qualities such as appropriateness, rightness to fit, not-simplistic and wholeness. All of these have in common the subsequent need for a purpose, a purpose which he calls the \emph{Quality Without a Name} \citep{alexander_timeless_1979}. This quality, he says, is semantically elusive, but nonetheless exists; it is, ultimately, the quality which sustains life, a conclusion which he reached after extensive empirical research: no one can name it precisely, but everyone knows what it refers to. It is the quality which makes one feel at home, which makes one feel like things make sense in a deep, unexplicable way\footnote{"\emph{It is always looking at two entities of some kind and comparing them as to which one has more life. It appears to be a rank bit of subjectivity. [\dots] It turns out that these kind of measurements do correlate with real structural features in the thing and with the presence of life in the thing measured by other methods, so that it isn't just some sort of subjected I groove to this, and I don't groove to that and so on. But it is a way of measuring a real deep condition in the particular things that are being compared or looked at.}" \citep{alexander_keynote_1996}}. This reluctance to being linguistically explicited is echoed in the work of the craftsman, where a practitioner often finds herself showing rather than telling \citep{pye_nature_2008}, another domain with which software developers identify, explicited in \ref{subsubsec:crafting-software}. + +Among the adjectives used to circle around this quality are whole, comfortable, free, exact, egoless, eternal \citep{alexander_timeless_1979}. Some of these qualities can also be found in software development, particularly wholeness and comfort. A whole program is a program which is not missing any features, whose encounter (or lack thereof) might cause a crash. If if a function implies a systematic design, such systematic design is not compromised by the lacking of some parts. Conversely, it is also a program which does not have extraneous—useless—features. -Among the adjectives used to circle around this quality are whole, comfortable, free, exact, egoless, eternal \citep{alexander_timeless_1979}. Some of these qualities can also be found in software development, particularly wholeness and comfort. A whole program is a program which is not missing any features, whose encounter (or lack thereof) might cause a crash. Conversely, it is also a program which does not have extraneous—useless—features. A comfortable program text being is a program which might be modified without fear of some unintended side-effects, without inivisible dependencies which might then compromise the whole. There is enough separation of concerns to ensure a somewhat safe working area, in which one can engage in epistemic probing assuming that things will not be breaking in unexpected ways; being whole, it also provides a higher sense of meaning by realizing how one's work relates to the rest of the construction. The implication here is that comfort derives from a certain kind of knowledge, a knowledge of how things (spatial arrangements, technical specifications, human functions) are arranged, how they relate to each other, how they can be used and modified. +A comfortable program text being is a program which might be modified without fear of some unintended side-effects, without inivisible dependencies which might then compromise the whole. There is enough separation of concerns to ensure a somewhat safe working area, in which one can engage in epistemic probing assuming that things will not be breaking in unexpected ways; being whole, it also provides a higher sense of meaning by realizing how one's work relates to the rest of the construction. The implication here is that comfort derives from a certain kind of knowledge, a knowledge of how things (spatial arrangements, technical specifications, human functions) are arranged, how they relate to each other, how they can be used and modified. To complement this theoretical pendant, Alexander conducted empirical research to find examples of such qualities, in a study led at the University of Berkley which resulted in his most popular book, \emph{A Pattern Language} \citep{alexander_pattern_1977}. In it, he and his team lists 253 patterns which are presented as to form a kind of language, akin to a Chomskian generative grammar, re-usable and extendable in a very concrete way, but without a normative, quasi-biological component. It turns it out that such a documentation, of re-usable configuration and solutions for contextual problem-solving, had a significant echo with computer scientists. -A whole field of research developed around the idea expressed in \emph{A Pattern Language}, at the crossover between computer science and architecture\footnote{See, for instance, the \emph{Beautiful Software Initiative} as an organized effort to develop Alexander's theses on growth, order, artefact and computation \citep{bryant_beautiful_2022}} of distinct, self-contained but nevertheless composable components. In Alexandrian terms, they are a triad, which expresses a relation between a certain context, a problem, and a solution. Similarly to architectural patterns, these emerged in a bottom-up fashion: individual software developers found that particular ways of writing and organizing code were in fact extensible and reusable solutions to common problems which could be formalized and shared with others. Patterns enable a cognitive engagement based on a feeling of familiarity, and of recognizing affordances. This form of engagement relies on the taking of epistemic actions in order to understand a particular system, as highlighted in \ref{subsec:psychology-programming}. +A whole field of research developed around the idea expressed in \emph{A Pattern Language}, at the crossover between computer science and architecture\footnote{See, for instance, the \emph{Beautiful Software Initiative} as an organized effort to develop Alexander's theses on growth, order, artefact and computation \citep{bryant_beautiful_2022}.} of distinct, self-contained but nevertheless composable components. In Alexandrian terms, they are a triad, which expresses a relation between a certain context, a problem, and a solution. Similarly to architectural patterns, these emerged in a bottom-up fashion: individual software developers found that particular ways of writing and organizing code were in fact extensible and reusable solutions to common problems which could be formalized enough to be shared with others. Patterns enable a cognitive engagement based on a feeling of familiarity, and of recognizing affordances. -Extending from the similarities of structure and function between software and architecture mentioned above, it is the lack of learning from practical successes and failures in the field which prompted interest in Alexander's work, along with the development of Object-Oriented Programming, first through the Smalltalk language\footnote{For an extensive history of the design and development of the Smalltalk hardware and software, see \citep{kay_early_1993}}, then with C++, until today, as most of the programming languages in 2023 include some sort of object-orientation and encapsulation. What Object-orientation does, is that it provides a semantic structure to the program, reflected in the syntactic structure: objects are conceptual entities, with states and actions\footnote{In OOP, the states and actions of an object are respectively called member fields and methods}. This enables such objects to be re-used within a program text, and even across program texts. +Extending from the similarities of structure and function between software and architecture mentioned above, it is the lack of learning from practical successes and failures in the field which prompted interest in Alexander's work, along with the development of Object-Oriented Programming, first through the Smalltalk language\footnote{For an extensive history of the design and development of the Smalltalk hardware and software, see Alan Kay's \emph{Early History of Smalltalk} \citep{kay_early_1993}.}, then with C++, until today, as most of the programming languages in 2023 include some sort of object-orientation and encapsulation. What object-orientation does, is that it provides a semantic structure to the program, reflected in the syntactic structure: objects are conceptual entities, with states and actions, as discussed in \ref{subsubsec:modelling-complexity} and shown in \ref{code:representation}. This enables such objects to be re-used within a program text, and even across program texts. The similarities between a pattern and an object, insofar as they are self-contained solutions to contextual situations that emerged through practice, and resulting from empirical deductions, caught on with software developers as a technical solution with a social inflection, rather than a computational focus. Writing in \emph{Patterns of Software}, with a foreword by Alexander, Richard P. Gabriel addresses this shift from the machine to the human: @@ -364,14 +378,14 @@ \subsection{Patterns and structures} The promise of object-oriented programming—and of programming languages themselves—has yet to be fulfilled. That promise is to make plain to computers and to other programmers the communication of the computational intentions of a programmer or a team of programmers, throughout the long and change-plagued life of the program. The failure of programming languages to do this is the result of a variety of failures of some of us as researchers and the rest of us as practitioners to take seriously the needs of people in programming rather than the needs of the computer and the compiler writer. \citep{gabriel_patterns_1998} \end{quote} -The real issue raised here in programming seems to be, again, not to speak to the machine, but to speak to other humans. This complexity of communication, had always asked to be solved, perhaps at this point in the form of object-orientation. While understanding software is hard, creating, identifying, and formalizing patterns into re-usable solutions turns out to be at least as hard \citep{taylor_patterns_2001}. Part of this comes from a lack of visibility of code bases (most of them being closed source), but also from the series of various economic and time-sensitive constraints to which developers are subject to (and echoes those in the field of architecture), and which result in moving from making something great to making something good enough to ship. The promise of software patterns seemed to offer a way out by—laboriously—codifying know-how. Interestingly, while the increase in software quality has been found to result from the application of engineering practices \citep{hoare_how_1996}, the discovery and formalization of the software patterns takes place through the format of writers' workshops\footnote{As taken from the website of the 2022 Pattern Languages of Programming conference: "At PLoP, we focus on improving the written expression of patterns through writers' workshops. You will have opportunities to refine and extend your patterns with the assistance of knowledgeable and sympathetic patterns enthusiasts and to work with others to develop pattern languages" \citep{guerra_plop_2022}.}. +The real issue raised here in programming seems to be, again, not to speak to the machine, but to speak to other humans. The programming paradigm of object-orientation aims at solving such complexity in communication. While understanding software is hard, creating, identifying, and formalizing patterns into re-usable solutions turns out to be at least as hard \citep{taylor_patterns_2001}. Part of this comes from a lack of visibility of code bases (most of them being closed source), but also from the series of various economic and time-sensitive constraints to which developers are subject to (and echoes those in the field of architecture), and which result in moving from making something great to making something good enough to ship. The promise of software patterns seemed to offer a way out by—laboriously—codifying know-how. Interestingly, while the increase in software quality has been found to result from the application of engineering practices \citep{hoare_how_1996}, the discovery and formalization of the software patterns takes place through the format of writers' workshops\footnote{As taken from the website of the 2022 Pattern Languages of Programming conference: "\emph{At PLoP, we focus on improving the written expression of patterns through writers' workshops. You will have opportunities to refine and extend your patterns with the assistance of knowledgeable and sympathetic patterns enthusiasts and to work with others to develop pattern languages.}" \citep{guerra_plop_2022}.}, presenting a different mode of knowledge transmission. Throughout his work, Gabriel draws from the work of an architect to weave parallels between his experience as a software developer and as a poetry writer, drawing concepts from the latter field into the former, and inspecting it through the lens of a pattern languages of built concrete or abstract structures. We develop further two concepts in particular, and show how \emph{habitability} and \emph{compression} enable an understanding of such structures. \subsubsection{Compression and habitability in functional structures} \label{subsubsec:compression-habitability} -Source code is thus also an inherently spatial medium, with entrypoints, extracted packages, parallel threads of executions, relative folders and directories and endless jump between files. Reading a program text therefore matches more closely an excursion into a foreign territory whose map might be misleading, than reading a book from start to finish. For instance, \ref{graphic:code-city} builds on a longer history of using the city as a metaphor for large code bases, and visualizes classes, packages and version in three dimensions. +We have seen how source code is an inherently spatial medium, with entrypoints, extracted packages, parallel threads of executions, relative folders and directories and endless jump between files. Reading a program text therefore matches more closely an excursion into a foreign territory whose map might be misleading, than reading a book from start to finish. For instance, \ref{graphic:code-city} builds on a longer history of using the city as a metaphor for large code bases, and visualizes classes, packages and version in three dimensions. \begin{figure} \includegraphics[width=0.8\textwidth,height=\textheight,keepaspectratio,center]{codecity_screenshot.png} @@ -379,9 +393,9 @@ \subsubsection{Compression and habitability in functional structures} \label{graphic:code-city} \end{figure} -Given this somewhat literal mapping of source code structure onto urban structure, and given the abstract structure of object-oriented code, a reader of source code will need to find their bearings and orient themselves\footnote{"Exploring a source code repository always starts with finding out what the OS will select as the entry point. 99\% of the time it means finding the `int main(int,char**)` function" says Fabien Sanglard on the topic of reverse-engineering code-bases \citep{sanglard_game_2018}}. +Given this somewhat literal mapping of source code structure onto urban structure, and given the abstract structure of object-oriented code, a reader of source code will need to find their bearings and orient themselves\footnote{"\emph{Exploring a source code repository always starts with finding out what the OS will select as the entry point. 99\% of the time it means finding the `int main(int,char**)` function}" says Fabien Sanglard on the topic of reverse-engineering code-bases \citep{sanglard_game_2018}.}. Once the entrypoint is found, the programmer starts to explore the programmed maze and attempts to make sense of their surroundings, as a step towards the construction of mental models. -One of the overlaps between architecture and software is their relation to function. Particularly in software, this relation is accompanied by the assumption that others will want to modify and extend source code. Other pieces of code might just be satisfying in being read or deciphered (as we've seen in source code poetry in \ref{subsubsec:code-poetry} or with hackers in \ref{subsec:hackers}) but this assumption of interaction with the code brings in another concept, that of \emph{habitability}. In Gabriel's terms, it is +Both inhabitants in a building and programmers in a code base have a tendency to be there to \emph{accomplish something}, whether it might be living, working or eating for the former, or fixing, learning or modifying for the latter.s Particularly in software, one of the correlated functions of a program text is to be maintainable; that is, it must be made under the assumption that others will want to modify and extend source code. Other pieces of code might just be satisfying in being read or deciphered (as we've seen in source code poetry in \ref{subsubsec:code-poetry} or with hackers in \ref{subsec:hackers}) but this assumption of interaction with the code brings in another concept, that of \emph{habitability}. In Gabriel's terms, it is \begin{quote} the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. \citep{gabriel_patterns_1998} @@ -390,26 +404,34 @@ \subsubsection{Compression and habitability in functional structures} In a sense, then, beautiful code is also code that is clear enough to inform action and, well-organized enough to warrant actually taking that action. For instance, writing in the ACM Queue, an anonymous programmer discusses the beauty in a code where the separation between which sections of the source are hardware-dependent and which are not, as seen in \ref{code:hardware-separation}. In that example, it is clear to the programmer what the problem-domain is: counter incrementation, high-performance computation, or a specific Intel chip. \begin{listing} - \inputminted{rust}{./corpus/hardware_separation.h} - \caption{In the C family of languages, header files represent the overall structure of the program. This program text is defining the overall structure and the extent to which it interacts with specific hardware.} + \inputminted{c}{./corpus/hardware_separation.h} + \caption{This header file defines the structure of a program, both in its human use, in its interaction with hardware components, and its decoupling of hardware and software elements.} \label{code:hardware-separation} \end{listing} -This distinction relates to Alexander's property of comfort, by affording involvement instead of estrangement. A specific instance of habitability, in software patterns, might be difficult to pinpoint, but can pop up in some cases: a beautiful commit is a commit which adds a significant feature, and yet only change the lines of the code that are within well-defined boundaries (e.g. a single function), leaving the rest of the codebase untouched, and yet affecting it in a fundamental way. +There are several things which we can identify here. First, the three lines at the top of the listing indicate version numbers, which do not hold any computational functionality, but rather a human functionality: it communicates that this software considers change and evolution as core part of its source code, inviting the programmer reader to further modify it\footnote{From the anonymous programmer: "\emph{The engineer clearly knew his software would be modified not only by himself but also by others, and he has specifically allowed for that by having major, minor, and patch version numbers. Simple? Yes. Found often? No.}" \citep{vicious_beautiful_2008}.} + +Second, the line defining the types of CPUs supported by the software is written in human-intelligible way, rather than a cryptic hexadecimal notation\footnote{"\emph{Nothing is more frustrating when working on a piece of software than having to remember yet another stupid, usually hex, constant. I am not impressed by programmers who can remember they numbered things from 0x100 and that 0x105 happens to be significant. Who cares? I don’t. What I want is code that uses descriptive names. Also note the constants in the code aren’t very long, but are just long enough to make it easy to know in the code which chip we’re talking about.}" \citep{vicious_beautiful_2008}.}. While the CPUs are ultimately represented in hexadecimal notation, the effort is made to render things intelligible to and quickly retrievable from the programmer's memory. + +Finally, the \lstinline{struct pmc_mdep} is a shorthand notation for "machine-dependent". In an era in which software can theoretically be executed on different hardware architectures, it is welcome to make the difference between the variables themselves, which apply across platform, and the values of these variables, which need to be changed per platform\footnote{"\emph{It would seem obvious that you want to separate the bits of data that are specific to a certain type of CPU or device from data that is independent, but what seems obvious is rarely done in practice. The fact that the engineer thought about which bits should go where indicates a high level of quality in the code.}" \citep{vicious_beautiful_2008}.}. This is a good example of a separation of concerns: it is made clear which parts of the program text the programmer needs to pay attention to, and can change, and which parts of the program texts she needs not be concerned with. For a further example of separation of concerns, one could point a beautiful commit is a commit which adds a significant feature, and yet only change the lines of the code that are within well-defined boundaries (e.g. a single function), leaving the rest of the codebase untouched, and yet affecting it in a fundamental way. -Still, such a feature of habitability, of supporting life, doesn't specify at all what it could, or should, look like. Rather, we get from Alexander a negative definition: +Habitability, then, is a combination of acknowledgment by the writer(s) to the reader(s) of the source, by referring to the evolution over time of the software, along with the use of intelligible names and separation of concerns. This distinction relates to Alexander's property of comfort, by affording involvement instead of estrangement. Still, such a feature of habitability, of supporting life, doesn't specify at all what it could, or should, look like. Rather, we get from Alexander a negative definition: \begin{quote} - The details of a building cannot be made alive when they are made from modular parts... And for the same reason, the details of a building cannot be made alive when they are drawn at a drawing board. \citep{alexander_timeless_1979} + The details of a building cannot be made alive when they are made from modular parts\dots And for the same reason, the details of a building cannot be made alive when they are drawn at a drawing board. \citep{alexander_timeless_1979} \end{quote} -If modularity itself is at odds with making good (software) constructions, then its implementation under the terms of an object-oriented programming paradigm becomes complicated. Indeed, the technical formalization of the field came with the release of the \emph{Design Patterns: Elements of Reusable Object-Oriented Software} book, which lists 23 design patterns implementable in software \citep{gamma_design_1994}. Its influence (in terms of copies sold, and in terms of papers, conferences and working groups created in its wake) is undeniable, with Alexander himself giving a keynote address at the ACM two years after the release. It has, however, been met with some criticism. +If modularity itself is at odds with making good (software) constructions, then its implementation under the terms of an object-oriented programming paradigm becomes complicated. Indeed, the technical formalization of the field came with the release of the \emph{Design Patterns: Elements of Reusable Object-Oriented Software} book, which lists 23 design patterns implementable in software \citep{gamma_design_1994}. Its influence, in terms of copies sold, and in terms of papers, conferences and working groups created in its wake, is undeniable, with Alexander himself giving a keynote address at the ACM two years after the release. It has, however, been met with some criticism. -Some of this criticism is that patterns are "external", they look like they come from somewhere else, and are not adapted to the code. In this sense, they join Alexander in being wary of constructions which do not integrate fully within their environments, which do not, in an organic sense, allow for a piecemeal growth\footnote{Addressing this concern, the failure of strict top-down hierarchies in software development resulted in the agile methodology for business teams}. If patterns express relations between contexts, problems and solutions, then it seems that one of the main complaints of developers looking at their code and seeing chunks of foreign code dumped in the middle to fix some generic problem\footnote{The example of the best pattern to retro-fit an air conditionner on a building would be a non-problem if the air-conditionning had been designed in from the get-go \citep{coplien_patterns_2009}.}, is the lack of understanding of context offered by those proposed solutions. In this, blindly applying patterns from a textbook might be a solution, but it's not an elegant one. This criticism also finds its echoes in the Scruton's analysis of architectural styles; rules and conventions, while present in architecture, are often adopted only to be departed from—re-interpreted and adapted to the context of the building \citep{scruton_aesthetics_2013}. +Some of this criticism is that patterns are "external", they look like they come from somewhere else, and are not adapted to the code. In this sense, this corroborates Alexander in being wary of constructions which do not integrate fully within their environments, which do not, in an organic sense, allow for a piecemeal growth\footnote{Addressing this concern, the failure of strict top-down hierarchies in software development resulted in the \emph{agile} methodology for business teams, now one of the most popular ways of building software products.}. If patterns express relations between contexts, problems and solutions, then it seems that one of the main complaints of developers is that they might, one day, look at the code they were working on and see chunks of foreign snippets dumped in the middle to fix some generic problem, with no understanding for specifics, nor fit in the existing structure. This is judged negatively due to its lack of understanding of context offered by those proposed solutions. In this, blindly applying patterns from a textbook might be a solution, but it's not an elegant one. This criticism also finds its echoes in the Scruton's analysis of architectural styles; rules and conventions, while present in architecture, are often adopted only to be departed from—re-interpreted and adapted to the context of the building \citep{scruton_aesthetics_2013}. -While patterns might operate at a more structural level, hinting at different parts of code, and its overall organization, one can also turn to a more micro-level. What can a detail do in our understanding of structures? Sometimes decried, sometimes praised in architecture, the detail fulfills mutliple roles: compressing meaning and testifying for materiality. +One aspect that has been eluded so far is therefore that of the programming languages used by the programmer. Indeed, one doesn't write Ruby like one writes Java, C++, or Lisp. If materiality is a core component of eliciting an aesthetic experience in an architectural context, then programming languages are the material of source code, and offer a specific context to the writing and reading of the program text. -Both Scruton and Rancière mention the detail as an essential architectural element. Without contributing to the structural soundness of the construction, it nonetheless contributes to its expressiveness. A blend of the cognitive and sensual is also characteristic of Scruton's "imaginative perception", understood as the perception of the details of built structures, and their extrapolation into the imaginary. This imagination depends on the interpretative choices in parsing ambiguous or multiform aspects of the built environment. The detail contributes to the stylistic convention of the creation: +A final criticism to software patterns is that they are language-independent. As such, they are often workarounds for features that a particular programming language doesn't allow from the get-go, or offers simpler implementations than the pattern's\footnote{For instance, Peter Norvig highlights that most patterns in the original book have much simpler implementations in Lisp than in C++ or Smalltalk \citep{norvig_design_1998}}. + +While patterns might operate at a more structural level, hinting at different parts of code, and its overall organization, one can also turn to a more micro-level. What can a detail do in our understanding of structures? Sometimes decried, sometimes praised in architecture, the detail fulfills mutliple roles: acting as a meaningful interface, compressing meaning and testifying for materiality. + +Both Scruton and Rancière mention the detail as an essential architectural element. Without contributing to the structural soundness of the construction, it nonetheless contributes to its expressiveness. A blend of the cognitive and sensual is also characteristic of Scruton's "imaginative perception", understood as the perception of the details of built structures, and their extrapolation into the imaginary. Indeed, the experience of the user is based on the points at which it sensually grasps its environment: the detail is therefore the point of interaction between the human and the structure. This imagination depends on the interpretative choices in parsing ambiguous or multiform aspects of the built environment. The detail contributes to the stylistic convention of the creation: \begin{quote} Convention, by limiting choice, makes it possible to 'read' the meaning in the choices that are made \dots for style is used to 'root' the meanings which are suggested to the aesthetic understanding, to attach them to the appearance from which they are derived. \citep{scruton_aesthetics_2013} @@ -419,48 +441,53 @@ \subsubsection{Compression and habitability in functional structures} Compression is a concept introduced by Gabriel in response to pattern design. In narrative and poetic text, it is the process through which a word is given additional meaning by the rest of the sentence. In a sentence such as "\emph{Last night I dreamt I went to Manderley again.}" \citep{dumaurier_rebecca_1938}, the reader is unlikely to be familiar with the exact meaning of \emph{Manderley}, since this is the first sentence of the novel. However, we can infer some of the properties of Manderley from the rest of the sentence: it is most likely a place, and it most likely had something to do with the narrator's past, since it is being returned to. A similar phenomenon happens in source code, in which the meaning of a particular expression or statement can be derived from itself, or from a larger context. In object-oriented programming, the process of inheritance across classes allows for the meaning of a particular subclass to be mostly defined in terms of the fields and methods of its subclasses—its meaning is compressed by relying on a semantic environment, which might or not be immediately visible. -This, Gabriel says, induces a tension between extendability (to create a new subclass, one must only extend the parent, and only add the differentiating aspects) and context-awareness (one has to keep in mind the whole chain of properties in order to know exactly what the definition of an interface that is being extended really is). Resolving such a tension, by including enough information to hint at the context, while not over-reaching into verbosity, is a thin line of being self-explanatory without being verbose. For instance, Casey Muratori explores the process of compression in refactoring a program text, first by distinguish semantic compression from syntactic compression\footnote{"\emph{Like, literally, pretend you were a really great version of PKZip, running continuously on your code, looking for ways to make it (semantically) smaller. And just to be clear, I mean semantically smaller, as in less duplicated or similar code, not physically smaller, as in less text, although the two often go hand-in-hand.}" \citep{muratori_semantic_2014}}, and then honing in on what makes a compression successful\footnote{"\emph{Ah! It's like a breath of fresh air compared to the original, isn't it? Look at how nice that looks! It's getting close to the minimum amount of information necessary to actually define the unique UI of the movement panel, which is how we know we're doing a good job of compressing.} \citep{muratori_semantic_2014}}. Transitioning from uncompressed code (\ref{code:uncompressed}) to compressed code (\ref{code:compressed}) allows the programmer to understand broad patterns about the overall architecture of the program text—here, how to display a clickable panel on a UI widget. +This, Gabriel says, induces a tension between extendability (to create a new subclass, one must only extend the parent, and only add the differentiating aspects) and context-awareness (one has to keep in mind the whole chain of properties in order to know exactly what the definition of an interface that is being extended really is). Resolving such a tension, by including enough information to hint at the context, while not over-reaching into idiosyncracy, is a thin line of being self-explanatory without being verbose. + +For instance, Casey Muratori explores the process of compression in refactoring a program text, first by distinguishing semantic compression from syntactic compression\footnote{"\emph{Like, literally, pretend you were a really great version of PKZip, running continuously on your code, looking for ways to make it (semantically) smaller. And just to be clear, I mean semantically smaller, as in less duplicated or similar code, not physically smaller, as in less text, although the two often go hand-in-hand.}" \citep{muratori_semantic_2014}}, and then honing in on what makes a compression successful\footnote{"\emph{Ah! It's like a breath of fresh air compared to the original, isn't it? Look at how nice that looks! It's getting close to the minimum amount of information necessary to actually define the unique UI of the movement panel, which is how we know we're doing a good job of compressing.} \citep{muratori_semantic_2014}}. Transitioning from uncompressed code, shown in \ref{code:uncompressed} to compressed code, shown in\ref{code:compressed}, allows the programmer to understand broad patterns about the overall architecture of the program text—here, the function is to display a clickable panel on a user interface. +% - Listing 44: again, the point of these examples as an illustration of refactoring is also not clear, should be commented a lot more \begin{listing} \inputminted[]{c}{./corpus/uncompressed.c} \caption{genalloc.c, Basic general purpose allocator for managing special purpose memory from the Linux Kernel, displaying examples of source-code spatiality \citep{muratori_semantic_2014}} \label{code:uncompressed} \end{listing} +The difference we can see between the compressed and uncompressed goes beyond the number of lines used for the same functionality. A first clue in terms of semantics is the use of strictly syntactic block markers: \{ and \}. There are here stricly to delimitate a code block, with no semantic meaning to the computer. While the uncompressed listing shows all the separate elements needed for a button to exist (such as \lstinline{x0}, \lstinline{y0}, \lstinline{my_height}, etc.), while the compressed listings as encapsulated them into an object called \lstinline{Panel_Layout}, thus abstracting away from the programmer's mind the details of such a panel. This encapsulation then enables a further compression of the program: by adding the \lstinline{push_button()} method on the \lstinline{layout}, the compressed code realizes the same functionality of checking for button presses for each button, but ties it to a specific object and, due to the implementation, includes the name of the button being pressed on the same line as the check happens, rather than a line apart in the uncompressed example. + \begin{listing} \inputminted[]{c}{./corpus/compressed.c} \caption{genalloc.c, Basic general purpose allocator for managing special purpose memory from the Linux Kernel, displaying examples of source-code spatiality \citep{muratori_semantic_2014}} \label{code:compressed} \end{listing} -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 +By compressing the source code and abstracting some concepts, such as the button, one can also gain understanding about the rest of the program text. By showing details of practices and styles, a programmer can extrapolate from a small fragment to a larger structure. 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} \end{quote} -Finally compression isn't so much a problem in poetry since, ultimately, the definitions of each words aren't quite limited to the poet's own mind but, as we've seen, also existing in the broad conceptual structures which readers hold. However, since all aspects of a program is always, and by definition, explicitly defined, programmers thus have the ultimate say on the definition of most of the data and functions described in code. Programmers create their own semantic contexts while, at the same time, having to take into account the context of the machine and the context of the problem. +In poetry, compression presents a different problem since, ultimately, the definitions of each words are not limited to the poet's own mind but also exist in the broad conceptual structures which readers hold. However, since all aspects of a program is always explicitly defined, programmers thus have the ultimate say on the definition of most of the data and functions described in code. As such, they create their own semantic contexts while, at the same time, having to take into account the context of the machine, the context of the problem, and the context(s) that their reader(s) might be coming from. -In his 1951 lecture, "Building, Dwelling, Thinking", Martin Heidegger offers a perspective on these two forms of architecture: top-down and bottom-up, respectively equating them to building as erecting, and building as cultivating. To dwell is an engagement of thought and of action, one which leads to the construction of buildings in particular locations\footnote{Speaking of a farmhouse in the Schwarzwald, he describes the chain of creation as such: \emph{" A craft which, itself sprung from dwelling, still uses its tools and frames as things, built the farmhouse.}} \citep{heidegger_building_1975}. This active existence in time and space, allowing for deliberate thought and action and resulting in a better structure also equates to Gabriel's concept of habitability: +We now see that, within the same need for the appreciation of function, architecture can take opposite approaches: seeing a building as an abstract design, or as a concrete construction. In his 1951 lecture, "Building, Dwelling, Thinking", Martin Heidegger offers a perspective on these two forms of architecture. He equates top-down and bottom-up to, respectively, building as erecting, and building as cultivating. Ultimately, both of these approaches relate to human dwelling in a given location. To dwell is an engagement of thought and of action, one which leads to the construction of buildings in particular locations, arguing for a contextual adequacy of human structures to their environment\footnote{Speaking of a farmhouse in the Schwarzwald, he describes the chain of creation as such: \emph{" A craft which, itself sprung from dwelling, still uses its tools and frames as things, built the farmhouse.}} \citep{heidegger_building_1975}. This active existence in time and space, allowing for deliberate thought and action and resulting in a better structure also equates to Gabriel's concept of habitability: \begin{quote} Habitability is the characteristic of source code that enables programmers coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently \dots Software needs to be habitable because it always has to change \dots What is important is that it be easy for programmers to come up to speed with the code, to be able to navigate through it effectively, to be able to understand what changes to make, and to be able to make them safely and correctly. \citep{gabriel_patterns_1998} \end{quote} -As Heidegger returns to the etymological root of dwelling (\emph{bauern}) in order to connect it to the possible experience of the world humans can have through language, he grounds our experience in context. His though, between earth, man, techne and construction, hints at the essence that human construction—craft—as a consequence of thought and as a precedence to construction. Taking into accoun context and materiality, a final connection between software and architecture is actually with the field that predated, and complemented, architecture: craftsmanship. +As Heidegger returns to the etymological root of dwelling (\emph{bauern}) in order to connect it to the possible experience of the world humans can have through language, he grounds our experience in context. His though, between earth, man, \emph{techne} and construction, hints at the essence that human construction—craft—as a consequence of thought and as a precedence to construction. Taking into account context and materiality, a final connection between software and architecture is actually with the field that predated, and complemented, architecture: craftsmanship. \subsection{Material knowledge} \label{subsec:material-knoweldge} -Architecture as a field and the architect as a role have been solidified during the Renaissance \citep{pevsner_term_1942}, consecrating a separation of abstract design and concrete work. This shift obfuscates the figure of the craftsman, who is relegated to the role of executioner, until the arrival of civil engineering and blueprints overwhelmingly formalized the discipline. While computer science, through its abstract designs, echoes the modernist architect with its pure plans, the programmer, identifying itself with the craftsman, offers different avenues for knowing artefacts. +Architecture as a field and the architect as a role have been solidified during the Renaissance, consecrating a separation of abstract design and concrete work. This shift obfuscates the figure of the craftsman, who is relegated to the role of executioner, until the arrival of civil engineering and blueprints overwhelmingly formalized the discipline \citep{pevsner_term_1942}. While computer science, through its abstract designs, echoes the modernist architect with its pure plans, the programmer, identifying itself with the craftsman, offers different avenues for knowing artefacts. The architect emerged from centuries of hands-on work, while the computer scientist (formerly known as mathematician in the 1940s and 1950s) was first to a whole field of practitioners as programmers, followed by a need to regulate and structure those practices. Different sequences of events, perhaps, but nonetheless mirroring each other. On one side, construction work without an explicit architect, under the supervision of bishops and clerks, did indeed result in significant achievement, such as Notre Dame de Paris or the Sienna Cathedral. On the other side, letting go of structured and restricted modes of working characterizing computer programming up to the 1980s resulted in a comparison described in the aptly-named \emph{The Cathedral and the Bazaar}. This essay described the Linux project, the open-source philosophy it propelled into the limelight, and how the quantity of self-motivated workers without rigid working structures (which is not to say without clear designs) can result in better work than if made by a few, select, highly-skilled individuals \citep{raymond_cathedral_2001,henningsen_joys_2020}. -What we see, then, is a similar result: individuals can cooperate on a long-term basis out of intrinsic motivation, and without clear, individual ownership of the result; a parallel seen in the similar concepts of \emph{collective craftsmanship} in the Middle-Ages and the \emph{egoless programming} of today \citep{brooksjr_mythical_1975}. The further sections will investigate how such a phenomena of building complex structures through horizontal networks is possible, from both epistemological and aesthetic perspectives. +What we see, then, is a similar result: individuals can cooperate on a long-term basis out of intrinsic motivation, and without clear, individual ownership of the result; a parallel seen in the similar concepts of \emph{collective craftsmanship} in the Middle-Ages and the \emph{egoless programming} of today \citep{brooksjr_mythical_1975}. Building complex structures through horizontal networks and practical knowledge is therefore possible, with consequences in terms aesthetic apprecitations. -Craftsmanship in our contemporary discourse seems most tied to a retrospective approach: it is often qualified as that which was \emph{before} manufacture, and the mechanical automation of production \citep{thompson_study_1934}, preferring materials and context to technological automation. Following Sennett, we will use his definition of craftsmanship as \emph{hand-held, tool-based, intrinsically-motivated work which produces functional artefacts, and in the process of which is held the possibility for unique mistakes} \citep{sennett_craftsman_2009}. +Craftsmanship in our contemporary discourse seems most tied to a retrospective approach: it is often qualified as that which was \emph{before} manufacture, and the mechanical automation of production \citep{thompson_study_1934}, preferring materials and context to technological automation. Following Sennett's work on craftsmanship as a cultural practice, we will use his definition of craftsmanship as \emph{hand-held, tool-based, intrinsically-motivated work which produces functional artefacts, and in the process of which is held the possibility for unique mistakes} \citep{sennett_craftsman_2009}. -At the heart of knowledge transmission and acquisition of the craftsman stands the \emph{practice}, and inherent in the practice is the \emph{good practice}, the one leading to a beautiful result. The existence of an aesthetic experience of code, and the adjectives used to qualify it (smelly, spaghetti, muddy), already pointed at in \ref{subsec:lexical-fields}, already points at an appreciation of code beyond its formalisms and rationalisms, and towards its materiality. We now turn to the aesthetic experience of code within the broader context of the aesthetics of craftsmanship, highlighting code's specificity as a material. +At the heart of knowledge transmission and acquisition of the craftsman stands the \emph{practice}, and inherent in the practice is the \emph{good practice}, the one leading to a beautiful result. The existence of an aesthetic experience of code, and the adjectives used to qualify it (smelly, spaghetti, muddy), pointed at in \ref{subsec:lexical-fields}, already hints at an appreciation of code beyond its formalisms and rationalisms, and towards its materiality. A traditional perspective is that motor skills, with dexterity, care and experience, are an essential feature of a craftsman's ability to realize something beautiful \citep{osborne_aesthetic_1977}, along with self-assigned standards of quality \citep{pye_nature_2008,sennett_craftsman_2009}. These qualitative standards which, when pushed to their extreme, result in a craftsperson's \emph{style}, gained through practice and experience, rather than by explicit measurements \citep{pye_nature_2008} \footnote{See Pye's account of craftsmanship, and his intent to make explicit the question of quality craftsmanship and \emph{"answer factually rather than with a series of emotive noises such as protagonists of craftsmanship have too often made instead of answering it."} \citep{pye_nature_2008}}. Two things are concerned here, supporting the final result: tools and materials \citep{pye_nature_2008}. According to Pye, a craftsperson should have a deep, implicit knowledge of both, what they use to manipulate (chisels, hammers, ovens, etc.) as well as what they manipulate (stone, wood, steel, etc). @@ -474,11 +501,11 @@ \subsection{Material knowledge} He opens here up a solution to the paradox of the hand-made and the computer-automated, as programming emerges from the latter as a new skill. This very rise of automation has been criticized for the rise of a Osborne's "soulless society" \citep{osborne_aesthetic_1977}, and has triggered debates about authorship, creativity and humanity at the cross-roads between artificial intelligence and artistic practice \citep{mazzone_art_2019}. One avenue out of this debate is human-machine cooperation, first envisioned by Licklider and proposed throughout the development of Human-Computer Interaction \citep{licklider_mancomputer_1960,grudin_tool_2016}. If machines, more and more driven by computing systems, have replaced traditional craftsmanship's skills and dexterity, this replacement can nonetheless suggest programming as a distinctly 21st-century craftsmanship, as well as other forms of cratsmanship-based work in an information economy. -Beautiful code, code well-written, is indeed an integral part of software craftsmanship \citep{oram_beautiful_2007}. More than just function for itself, code among programmers is held to certain standards which turn out to hold another relationship with traditional craftsmanship—specifically, form following function. +Beautiful code, code well-written, is an integral part of software craftsmanship \citep{oram_beautiful_2007}. More than just function for itself, code among programmers is held to certain standards which turn out to hold another relationship with traditional craftsmanship—specifically, a different take on form following function. A craftsman's material consciousness is recognized by the anthropomorphic qualities ascribed by the craftsman to the material \citep{sennett_craftsman_2009}, the personalities and qualities that are being ascribed to it beyond the immediate one it posseses. Clean code, elegant code, are indicators not just of the awareness of code as a raw material that should be worked on, but also of the necessities for code to exist in a social world, echoing Scruton's analysis that architectural aesthetics cannot be decoupled from a social sense\footnote{"\emph{it is the aesthetic sense which can transform the architetct's task from the blind pursuit of an uncomprehended function into a true exercise of practical common sense.}" \citep{scruton_aesthetics_2013}}. As software craftsmen assemble in loose hierarchies to construct software, the aesthetic standard is \emph{the respect of others}, as mentioned in computer science textbooks \citep{abelson_structure_1979}. -Another unique feature of software craftsmanship is its blending between tools and material: code, indeed, is both. This is, for instance, represented at its extreme by languages like LISP, in which functions and data are treated in the same way \citep{mccarthy_lisp_1965}. In that sense, code is a material which can be almost seamlessly converted from information to information-\emph{processing}, and vice-versa; code as a material is perhaps the only non-finite material that craftspeople can work with—along with words\footnote{This disregards the impact of programming languages, the hardware they run on, and the data they process on the environment; see \citep{kurp_green_2008}}. +Another unique feature of software craftsmanship is its blending between tools and material: code, indeed, is both. This is, for instance, represented at its extreme by languages like LISP, in which functions and data are treated in the same way \citep{mccarthy_lisp_1965}. In that sense, source code is a material which can be almost seamlessly converted from information to information-\emph{processing}, and vice-versa; code as a material is perhaps the only non-finite material that craftspeople can work with—along with words\footnote{This disregards the impact of programming languages, the hardware they run on, and the data they process on the environment; see \citep{kurp_green_2008}}. Code, from the perspective of craft, is not just an overarching, theoretical concept which can only be reckoned with in the abstract, but also the very material foundation from which the reality of software craftsmanship evolves. An analysis of computing phenomena, from software studies to platform studies, should therefore take into account the close relationship to their material that software developers can have. As Fred Brooks put it, @@ -486,25 +513,23 @@ \subsection{Material knowledge} The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. \citep{brooksjr_mythical_1975} \end{quote} -So while there are arguments for developing a more rigorous, engineering conception of software development \citep{ensmenger_computer_2012}, a crafts ethos based on a materiality of code holds some implications both for programmers and for society at large: engagement with code-as-material opens up possibilities for the acknowledgement of a different moral standard. As Pye puts it, +So while there are arguments for developing a more rigorous, engineering conception of software development \citep{ensmenger_computer_2012}, a crafts ethos based on a materiality of code holds some implications both for programmers and for society at large: engagement with code-as-material opens up possibilities for the acknowledgement of a different moral standard\footnote{Writing about resilient web development, Jeremy Keith echoes this need for material honesty: "\emph{The world of architecture has accrued its own set of design values over the years. One of those values is the principle of material honesty. One material should not be used as a substitute for another. Otherwise the end result is deceptive \citep{keith_resilient_2016}. }"}. As Pye puts it, \begin{quote} [\dots] the quality of the result is clear evidence of competence and assurance, and it is an ingredient of civilization to be continually faced with that evidence, even if it is taken for granted and unremarked. \citep{pye_nature_2008} \end{quote} -Code well-done is a display of excellence, in a discipline in which excellence has not been made explicit. If most commentators on the history of craftsmanship, following Ruskin, lament the disappearance of a better, long-gone way of doing things, before computers came to automate everything, locating software as a contemporary iteration of the age-old ethos of craftsmanship nonetheless situates it in a longer tradition of intuitive, concrete creation. +Code well-done is a display of excellence, in a discipline in which excellence has not been made explicit. If most commentators on the history of craftsmanship lament the disappearance of a better, long-gone way of doing things, before computers came to automate everything, locating software as a contemporary iteration of the age-old ethos of craftsmanship nonetheless situates it in a longer tradition of intuitive, concrete creation. -The world of architecture has accrued its own set of design values over the years. One of those values is the principle of material honesty. One material should not be used as a substitute for another. Otherwise the end result is deceptive \citep{keith_resilient_2016}. One aspect that has been eluded so far is therefore that of the programming languages used by the programmer. Indeed, one doesn't write Ruby like one writes Java, C++, or Lisp. If materiality is a core component of eliciting an aesthetic experience in an architectural context, then programming languages are the material of source code, and offer a specific context to the writing and reading of the program text. +\spacersmall -A final criticism to software patterns is that they are language-independent. As such, they are often workarounds for features that a particular programming language doesn't allow from the get-go, or offers simpler implementations than the pattern's\footnote{For instance, Peter Norvig highlights that most patterns in the original book have much simpler implementations in Lisp than in C++ or Smalltalk \citep{norvig_design_1998}}. +To conclude this section, we have seen that architecture can offer us some heuristics when looking for aesthetic features which code can exhibit. Starting from the naïve understanding that form should follow function, we've examined how Alexander's theory of patterns, and its significant influence on the programming community\footnote{This theory has even spawned short-lived debates about his quality without a name on stackoverflow \citep{interstar_quality_2017}.}, points not just to an explicit conditioning of form to its function (in which case we would all write hand-made Assembly code), but rather to an elusive, yet present quality, which is both problem- and context-dependent. -To conclude this section, we've seen that architecture can offer us some heuristics when looking for aesthetic features which code can exhibit. Starting from the naïve understanding that form should follow function, we've examined how Alexander's theory of patterns, and its significant influence on the programming community\footnote{even spawning short-lived debates about his quality without a name on stackoverflow \citep{interstar_quality_2017}.}, points not just to an explicit conditioning of form to its function (in which case we would all write hand-made Assembly code), but rather to an elusive, yet present quality, which is both problem- and context-dependent. It is a quality that is aware of the context that the writer and reader bring with them, and of the context that it provides them, making it habitable. Software architecture and patterns aren't, however, explicitly praised for their beauty, perhaps because they disregard these contexts—by definition, they're high-level abstractions. Generic solutions are rarely elegant solutions. departing from our investigation of software as craftsmanship, and moving through towards a more abstract discipline, we turn to scientific aesthetics. +Along with the function of the program as an essential component of aesthetic judgment, our inquiry has also shown that program texts can present a quality that is aware of the context that the writer and reader bring with them, and of the context that it provides them, making it habitable. Software architecture and patterns are not, however, explicitly praised for their beauty, perhaps because they disregard these contexts, since they are higher-level abstractions; this implies that generic solutions are rarely elegant solutions. And yet, there is an undeniable connection between the beautiful and the universal. Departing from our investigation of software as craftsmanship, and moving through towards a more abstract discipline, we turn to scientific aesthetics. \section{Forms of scientific activity} \label{sec:aesthetic-scientific} -% a bit more on engineering, hacking and the folly, should be explained in the beginning of modernism - As programmers learned their craft from practice and immediate engagement with their material, computer science was concomittantly developing from a seemingly more abstract discipline. Mathematicians such as Alan Turing, John Von Neumann and Grace Hopper can be seen, not as the foreparents of the discipline of computing, but rather as standing on the shoulders of a long tradition of mathematicians. Computation is, as as such, one of the many branches of contemporary mathematics and, as it turns out, such a tradition has also reccuringly included references to aesthetics. After the metaphors of literature and the patterned structures of architecture, we conclude our analysis of the aesthetic relation of domains contingent to source code by looking at how mathematics integrate formal presentation. This section approaches the topic of aesthetics and mathematics in three different steps. First, we look at the objective or status of beauty in mathematics: are mathematical objects eliciting an aesthetic experience in and of themselves, or do they rely on the observer's perception? Considering the difference between abstract objects and their representation: is aesthetic representation ascribed to either, or to both? And what is the place of the observer in this judgment? Having established a particular focus on the representations of abstract objects, we then turn to the epistemic value of aesthetics, and how positive aesthetic representations in mathematics can enable insight and understanding. Finally, we complement this relation between knowledge and presentation and depart from the ends of a proof, and an evaluative appraisal of aesthetics in mathematics, by investigating the actual process of doing mathematics, concluding with topics of pedagogy and ethics. diff --git a/redaction/corpus/hardware_separation.h b/redaction/corpus/hardware_separation.h index 27a262d..201342f 100644 --- a/redaction/corpus/hardware_separation.h +++ b/redaction/corpus/hardware_separation.h @@ -1,7 +1,13 @@ +#define PMC_VERSION_MAJOR 0x03 +#define PMC_VERSION_MINOR 0x00 +#define PMC_VERSION_PATCH 0x0000 + /* * Kinds of CPUs known */ #define __PMC_CPUS() \ __PMC_CPU(AMD_K7, "AMD K7") \ __PMC_CPU(AMD_K8, "AMD K8") \ __PMC_CPU(INTEL_P5, "Intel Pentium") \ __PMC_CPU(INTEL_P6, "Intel Pentium Pro") \ __PMC_CPU(INTEL_CL, "Intel Celeron") \ __PMC_CPU(INTEL_PII, "Intel Pentium II") \ __PMC_CPU(INTEL_PIII, "Intel Pentium III") \ __PMC_CPU(INTEL_PM, "Intel Pentium M") \ __PMC_CPU(INTEL_PIV, "Intel Pentium IV") +// ... + /* * struct pmc_mdep * diff --git a/redaction/images/ishigami.jpg b/redaction/images/ishigami.jpg new file mode 100644 index 0000000..208affa Binary files /dev/null and b/redaction/images/ishigami.jpg differ diff --git a/redaction/thesis.bib b/redaction/thesis.bib index a2cc32d..ad2b325 100644 --- a/redaction/thesis.bib +++ b/redaction/thesis.bib @@ -42,6 +42,16 @@ @misc{akten_journey_2016 file = {/home/pierre/Zotero/storage/MAHAHRDH/a-journey-through-multiple-dimensions-and-transformations-in-space-the-final-frontier-d8435d81c.html} } +@misc{alexander_keynote_1996, + type = {Keynote}, + title = {Keynote {{Speech}} to the 1996 {{OOPSLA Convention}}}, + author = {Alexander, Christopher}, + year = {1996}, + address = {{San Jose}}, + urldate = {2023-08-01}, + file = {/home/pierre/Zotero/storage/ZRHUDEJ2/ieee.html} +} + @book{alexander_pattern_1977, title = {A {{Pattern Language}}: {{Towns}}, {{Buildings}}, {{Construction}}}, shorttitle = {A {{Pattern Language}}}, @@ -4790,6 +4800,22 @@ @article{moore_brain_2022 file = {/home/pierre/Zotero/storage/CXHVS2KK/000599.html} } +@article{moore_junya_2011, + title = {Junya {{Ishigami}}: {{Architecture}} of {{Air}}; {{Serpentine Gallery Pavilion}} 2011 \textendash{} Review}, + shorttitle = {Junya {{Ishigami}}}, + author = {Moore, Rowan}, + year = {2011}, + month = jul, + journal = {The Observer}, + issn = {0029-7712}, + urldate = {2023-08-01}, + abstract = {Rowan Moore on the delicate challenge of Junya Ishigami's barely visible work, and this year's Serpentine pavilion}, + chapter = {Art and design}, + langid = {british}, + keywords = {Architecture,Art and design,Culture,Design,Serpentine pavilion}, + file = {/home/pierre/Zotero/storage/6F6G6YA8/junya-ishigami-serpentine-pavilion-zumthor.html} +} + @inproceedings{morales_programmer_2020, title = {Programmer {{eXperience}}: {{A Set}} of {{Heuristics}} for {{Programming Environments}}}, shorttitle = {Programmer {{eXperience}}}, diff --git a/redaction/thesis.pdf b/redaction/thesis.pdf index f6b1167..cdcb263 100644 Binary files a/redaction/thesis.pdf and b/redaction/thesis.pdf differ diff --git a/redaction/todo.md b/redaction/todo.md index c0ccd11..7b33d6e 100644 --- a/redaction/todo.md +++ b/redaction/todo.md @@ -70,41 +70,29 @@ overall, I should keep in mind that I do not have a technical audience, and I sh ### architecture -In architecture, highlight the fact that the _detail_ is the point of interaction between the human and the structure. - -- p.248: mention what are the specific things in architecture: the main thing in architecture is about sight (develop this in the form/function section). ALSO SITE-SPECIFIC: materials+context. Architecture: building codes and requirements, that is not there in lit or math. architect is neither an engineer nor a fine artist. -- Figure 4.2: the plan and the program are different: this is a plan, and the program is different. the program is equivalent to the system requirements. -- Listing 42: hard to tell what this does, might not be worth keeping, or include an extensive discussion of separation of concerns. -- p.263: nick disagrees, don't say that compression isn't so much a problem in poetry, but rather a different kind of problem. -- Listing 44: again, the point of these examples as an illustration of refactoring is also not clear, should be commented a lot more -- p.280: graphical representation/diagram is not uniquely artistic, it is that it adds choices, and calls for attention. not just because its a circle does it mean its better, but rather because it's a different way to represent the same thing, which I argue implies the possibility for a value judgment. +- insert picture from ishigami +- add more code examples (check the architecture of open source applications?) + +### mathematics + +- p.280: graphical representation/diagram is not uniquely artistic, it is that it adds choices, and calls for attention. not just because its a circle does it mean its better, but rather because it's a different way to represent the same thing, which I argue implies the possibility for a value judgment. __check in original file there this maps__ - Listing 45: maybe give a diagrammatic representation of the linked list? there's an abstract concept, this text is a particular representation of it, and a diagram could be another. strip down the example to the very bare minimum, and include very robust and helpful discussion of that discussion. this is too obscure. - listing 46: regex matcher: regex is a formalism for processing text. convey that this is a complex problem, but that you can actually write a fairly simple program to implement it. In general, I should always discuss extensively the listings. - Listing 47: still write about refactoring, but maybe with a shorter program. use the simplest case that makes my point. make that point with elaboration and extent discussion. BUT ALSO PREFACE IT WITH A PYTHON EXAMPLE. So have two listings in the end. - allamanis, using ML for code generation and analysis, and mattt (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?) -- include \citep{dexter_embodied_2011} - [ ] put less code poems in this section, both nick and alexandre disagree, seem like it is a bit of a far-fetched example, because this is about the uselessness. __my counter-argument__ is that while it seems that code poetry is useless in the sense that art is useless, not directed, not productive, etc. it is nonetheless functional from the point of the machine, in that it does complex operations. One can also draw an equivalent with Sol Lewitt, and his sentences on conceptual art, in which the "idea is a machine that makes the art". It functions in the machine sense of the term, perhaps not on the human sense. Conversely, some algorithms function on the machine term, and not on the human term: we address this in section 5.3 (syntactical validity, operational semantics, intended semantics) - -### mathematics - - add wallen_form_1990 with his argument that mathematics rely on the fact that sight is our most developed sense - [ ] mathematics: add a discussion of dijkstra's shortest path algorithm? - mathematics: Barker, John, 2009, “Mathematical Beauty”, Sztuka i Filozofia, 35: 65–74. (A powerful defence of the claim that mathematical and logical proofs have aesthetic properties.) - -### meeting with nick - 28.12.2022 - -- for each of the aesthetic domains (lit, arch, eng, math), add source code examples to show what is similar, and what is different in source code vs. original domains -> __INTERTWINE!__ -- 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) -- e.g. 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? -- ask "why does the metaphor work?" -> how do they (a) combine (b) extend (c) question? -- look at all the metaphors that fit together (in the lit domain, the arch domain, etc.) -- metaphor of the `macro` (implies scale), of `scope`, of `global`, implies scale as well. `libraries` is also a metaphor that is literary. - 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 - [ ] __tools__ add to means of understanding and IDEs deciding how we write: +- [ ] __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 `scope`, of `global`, implies scale as well. `libraries` is also a metaphor that is literary. ## chap 1 - ideals