@ -7,7 +7,7 @@ Coding Contingencies (CC) is a procedural take on how different characters got t
How did they choose a particular programming language, a coding paradigm, a development environment, an infrastructure where to run the code, and so on? These are not just technical choices, but rather coding contingencies.
How did they choose a particular programming language, a coding paradigm, a development environment, an infrastructure where to run the code, and so on? These are not just technical choices, but rather coding contingencies.
Personal decisions, trending technologies, curiosity and boredom, to name a few. A talk on Code Golf as form of frugality, a collegue passionate about live coding that drags you to an algorave night, a crypto-boyfriend, the tech stack of a company, a drastic turn of events, etc. etc.
Personal decisions, trending technologies, curiosity and boredom, to name a few. A talk on esolanguages as form of frugality, a collegue passionate about live coding that drags you to an algorave night, a crypto-boyfriend, the tech stack of a company, a drastic turn of events, etc. etc.
These contingencies are situated in precise contexts.
These contingencies are situated in precise contexts.
Programming then is not just sharing code, but sharing context.
Programming then is not just sharing code, but sharing context.
@ -34,7 +34,8 @@ Using the simulation as a writing machine we can articulate these CC with some b
Partecipants entangle gradually, and do not come as a monolithic block.
Partecipants entangle gradually, and do not come as a monolithic block.
They can be imagined as lines: merging together and branching away, tying and loosening knots. (Ingold)
They can be imagined as lines: merging together and branching away, tying and loosening knots. (Ingold)
This leads to multi-facets characters, where not all the elements needs to interact with each other all the time. (Haraway)
This leads to multi-facets characters, where not all the elements needs to interact with each other all the time.
Their interfaces can be loose, they don't need to be one hundred percent compatible to come together. (Haraway)
4. Orientation
4. Orientation
@ -45,6 +46,120 @@ Using the simulation as a writing machine we can articulate these CC with some b
This procedure helps us to think about software as cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Software Studies, 2009), and not just as technical tool existing in a vacuum.
This procedure helps us to think about software as cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Software Studies, 2009), and not just as technical tool existing in a vacuum.
## notes for the intro
- this cuold be the whole thesis but ok
- intro is a readme file
- the intro is a first chapter to aknowledge software as cultural object
- and to propose software documentation as a surface to renegotiate the making of software
- the software and hardware circumstances of code (Marino, 2020)
- but also the relation with _non-code entities_ (Mackenzie, 2006)
- sociality around software
- how should the format of software documentation inform this writing ???
- could these premises be embedded in the simulation?
- Other approaches, more theoric
- (maybe this goes in another direction, keep for later)
- or it could be part of the key points
- refine approach refering to ANT ?
- Latour ~ Haraway ~ Barad
- ANT ~ Kin
- OOO quadruple object & Software as unknown ?
- maybe not here but
- every piece of source code is is only ever partial (Marino, 2020)
- then here is the plan
- _how should the format of software documentation inform this writing ???_
- defining the simulation
- outline key points
- Suspension of judgment
- Discrete temporality
- Partiality
- Orientation
- different ways to approach the relation betwen software and context
- each one could be used to highlight certain aspect
- Discrete Temporality
- a way to present how the hype for a particular coding language grows
- ie: list of trending video on yt, threads on twitter, conferences
- how languages get popular and then forgotten
- how these istogram video of language popularity are done ? find sources
- temporality could also be a way to explore events of the past
- not every simulation must be set in the present
- (or rewinding back simulating causes instead of effects)
- ie: Ulman account on childish developers culture (Close to the machine, Life in code)
- ie: Richard Gabriel timeline for example (Pattern of software)
- Temporality could also be non uniform!
- ie: using the timespan of new commits in a version control system, gradually fading away when a project stops being maintained
- Could be interesting to read What the Dormouse Said
- Suspension of Judgement
- exploration of margins, fy shuffle and normal distribution
- uncommon or absurd setup (why are they absurd?) (what is the norm?)
- meta exploration: or exploring thing we dont understand (software as unknown?) (like esolangs)
- a way to investigate and build on disproportion of means:
- ie: all the js of react + all the css of tailwind + all the backend infrastracture of netlify to run a TODO list
- ie: the extreme quest for frugality in permacomputing projects such as 100R or DuskOS
- is not redemption arc for bad guys
- Partiality
- (that could also be read as multiplicity)
- focus on the same actor in different contexts:
- ie redstone circuits
- used to develop a virtual minecraft into minecraft itself
- but also cited by hito steyerl when talking about the overflowing of internet into real life, as well as the sinking of real life into internet
- but also expanded by modders to build different red stone dialects, forking the original one
- another example is:
- reclaimed technology
- tech deployed for military purposes recontextualized for medical uses (find exact references look at software studies lexicon or bridle ! ways of being)
- Orientation
- level of details
- zoom out to outline trends
- less about single characters
- more about their surroundings
- online communities! investors! sponsor! etc.
- and then zoom in for wrapping up
- ideally: to a distance within reach ? is this naive?
- software as a mean to orientate narratives
- narratives as a mean to orientate software
- ideally: gravitating towards documentation as an ideal surface where to act
- to orientate our use of code in the world
- structure
- other than these four features of the simulation there should be a structure
- with a clear structure the simulation can be more heterogeneous
- aggregate materials and references
- no need to be discoursive
- could be evocative
- think are.na
- TODO:
- define steps of the simulation
- setup
- things to simulate
- how to define things (ANT & OOOg)
- iterate
- visit each thing for every iteration
- build on previous iterations
- how to break out from the loop ?
- how to introduce new things / actors ?
```
```
------+.
------+.
|`. | `.
|`. | `.
@ -94,11 +209,12 @@ let's define actors not for what they are but for what they do
