this section focuses on the applied practice of describing things to the computer. who does it, how they do it, and how they relate to it. it would particularly focus on the historical/sociological aspect of it, to start highlighting that there might be one concept of computing, but the reality of interacting with and thinking in terms of computation is not unidimensional. it establishes different categories of people writing source code: researchers, academics (teachers+students), professionals, hackers, amateurs and artists.
Engelbart’s NLS expanded the view of programmers from business analysts and artiﬁcial intelligence researchers to any information worker. Smalltalk originally focused on children as programmers. Hypercard was developed and distributed at Bill Atkinson’s insistence that “end users” need programming capabilities. (from this). And then they mention diy hacker and maker culture, beginner friendly arduino, max for live and youtube studio (I must define which ones I include, which ones I exclude, and why maybe the definition I want is one where there is a clear definition between programmer and end user?)
ref: lammers, programmers at work
I argue that aesthetics can help grasp software’s multitude.
There’s also this blog post about all the voices in source code. All the programmers that have given insight, all the copy paste from SO, etc.
see black, p. 101 for a reference to software management literature
the underhanded c code contest
this section extracts the features that are recurring in the discourses around beauty in source code. it does so by looking at how practical examples and theoretical statements either converge or diverge and how such statements are modulated by the aforeidentified communities. the common point identified, via the subjectivity of writing code, is the concept of the craft.
beauty as a lack of ambiguity, as efficient achievement of an aim (aim of frustration/clarity/imagination)
this first approach, by comparing both source and comment at the same time (taking texts which are explicitly described as being beautiful), explicitly highlights the requirements for source code to be beautiful.
[[mattt_as_we_may_code]] -> this is somewhat almost architecture, brings a hint
this second approach contrasts with the functional component of the first one, but nonetheless stands in relationship with it. the creative beauty, by defying traditional beauty standards, does help us highlight, through deviance, what the norm is. these texts on “creative beauty” include the classical perl poetry, code poems, IOCC, code poetry contest, etc.
[[sondheim_codework]] [[ward_authorship_of_generative_code]] [[knuth_literate_programming]]
beautiful proofs in geometry?
Elegance: Through a single lens, it communicates the problem it solves and the machinery of its solution.
[[fuller_software_elegance]] [[spinellis_reading_writing_code]] [[iverson_notation_as_tool_for_thought]]
this subsection also allow us to introduce the concept of craftsmanship and integrate it within a larger tradition of sennett/de certeau/rancière, and connect the practice of programmer to a longer history of craft, a history which in itself has beauty standards
the zen of python could tie in to that tradition
this includes practical tips and software craftsmanship
“to grok” -> an expression which means “to grasp vaguely, to have an intuitive understanding of”
this section focuses on “you will know when you see it”
Implementation as: THIS GOES WITH GOODMAN
practice is synthetic method, a method which regroups, which puts together.
craft might also start to connect to the aesthetics of the everyday. particularly, thomas leddy has an article called “Everyday surface aesthetic qualities: neat, messy, clean, dirty” that might be very good