@ -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 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.
Personal decisions, trending technologies, curiosity and boredom, to name a few. A talk on esolangs 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.
@ -48,44 +48,6 @@ This procedure helps us to think about software as cultural object. Something "d
## notes for the intro
## 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
- Discrete Temporality
- a way to present how the hype for a particular coding language grows
- a way to present how the hype for a particular coding language grows
@ -133,12 +95,6 @@ This procedure helps us to think about software as cultural object. Something "d
- and then zoom in for wrapping up
- and then zoom in for wrapping up
- ideally: to a distance within reach ? is this naive?
- 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
- structure
- other than these four features of the simulation there should be a structure
- other than these four features of the simulation there should be a structure
@ -148,17 +104,105 @@ This procedure helps us to think about software as cultural object. Something "d
- could be evocative
- could be evocative
- think are.na
- think are.na
- TODO:
- [SETUP]
- define steps of the simulation
- intro as a readme file
- brief & accessible
- setup
- things to simulate
- intro as simulation
- how to define things (ANT & OOOg)
- iterate
- aknowledge software as cultural object
- visit each thing for every iteration
- and propose software documentation as a surface
- build on previous iterations
- to renegotiate the making of software
- how to break out from the loop ?
- to create entry points
- how to introduce new things / actors ?
- to question who gets to participate
- outline key points of simulation as writing machine
- Suspension of judgment
- Discrete temporality
- Partiality
- Orientation
- [REQUIREMENTS]
- need things to simulate
- not only
- the software and hardware circumstances of code (Marino, 2020)
- but also
- the relations with _non-code entities_ (Mackenzie, 2006)
- actors
- programming languages
- use cases
- how to define things?
- Latour ~ Haraway ~ Barad
- ANT ~ kin
- OOO
- more than the parts
- less of what it does
- every piece of source code is is only ever partial (Marino, 2020)
- the whole is less than the sum of its parts (Harman, )
- OOO quadruple object
- Software as unknown
- Generate data
- use references as elements
- Ulman, Gabriel, 100R
- [ITERATE]
- Explore a combination
- Visit each element and elaborate on it
- Highlight aspects of simulation
- Repeat
- Repeat with other combination
- Need to understand how to format this!
- Meaning: One after the other or all in parallel?
- TBD
- different ways to approach the relation betwen software and context
- list of references
- Weathering Software Winter (100R)
- Close to the Machine, Life in Code (Ulman)
- Pattern of Software, (Gabriel)
- Red Stone Fenomenology?
- P5js issues?
- Paged.js?
- Screenless Office?
- Tidal Cycles?
- SI16?
- Need to understand what does make sense and what doesnot
- when things are vivid enough go on
- [INSERT DOCUMENTATION AS ELEMENT]
- introduce documentation as new element in each simulation
- look what it does, how it ripples through the system
- which other element relates with documentation?
- who has to write, who get to write, who is addressed, how is sustained, etc
