16 KiB
Notes for the intro
- with a clear structure the simulation can be more heterogeneous
- aggregate materials and references
- no need to simulate everything
- intro as a readme file
- Could be interesting to read What the Dormouse Said
- note that the simulation is a way to just touch on the issues, not to explore them thoroughly
Simulation overview
This introduction is not a written as a text, but runs a simulation.
Coding Contingencies (CC) is a procedural take on how different characters deal with code.
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 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 contexts. Programming then is not just sharing code, but sharing context. It's providing a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script.
Features
Using the simulation as a writing machine we can articulate these CC with some benefits:
-
Suspension of judgment
Within the scope of the simulation it's not necessary to label good or bad choices. (That would have been the case for a machine learning writing device, for example) One character could decide one morning to write their own operative system from scratch using Red Stone circuits in Minecraft, and it would be fine. Due to the nature of the process, even the most absurd starting point it's a valid and powerful narrative device. In this way it becomes easier to explore marginal cases, improbabilities, and non-conform situations.
-
Discrete temporality
A simulation does not happen all at once, instead it is a process that evolves through time. This happens in both discrete steps and long-term iterations. Discrete steps can be further subdivided or grouped together, with the possibility of magnifying details, and the ability of zooming in and out a story. Long-term iterations are a way to keep asking what's next? what's next? to the machine. At every cycle, the simulation reaches out to each partecipant and asks for an update. In this way all the actors and relations develop in parallel.
-
Partiality
Participants are defined gradually, and do not come as a monolithic block. They start as details, a label, a profession, an ideal, and then begin to entangle gradually. They can be imagined as lines: merging together and branching away, tying and loosening knots. (Ingold) This leads to multi-facets and situated (Haraway) subjects, 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.
-
Orientation
Zooming in and out from the particular, we get a glimpse of a more gradual and diffuse process. A subtle sense of direction emerge from the initial randomness. By design, the simulation articulates software as a mean to orientate, as well as being oriented by, these trajectories.
How does certain programming languages facilitate certain ways of thinking, and totally block some others?
Process
The simulation is structured as a series of stages:
-
Requirements
Where to decide and define the elements involved in the simulation.
-
Setup
Where we join these actors together in small combinations. These will be the starting worlds of the simulation. To keep things simple, each world will be a closed ecosystem, and there won't be explicit interaction between different ones.
-
Worlds simulation
At this point each world will be really dry and synthetic, defined just by some labels that state that an actor is a musician, the name of a programming language, etc.
0 do loop 1 for each world 2 for each participant 3 ask for updatesThe structure of the simulation resembles a nested loop: for each world visit each participant, and ask for updates. Actually, we can save resources simulating just the combinations we want to explore, and not all the worlds of the initial dataset. The more iterations, the deeper the simulation gets.
Being a writing machine more than a piece of software, the process could be thought as a slow simulation. One that benefits the understanding of such a device and the quality of the different stages, instead of the quantity of iterations and generated data. A way to witness code and non-code entities (Mackenzie, 2006) coming together and shaping each other.
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.
-
Introduce documentation
After some iterations each world will grow a network of actors to play with. Once reached a sufficient mature state, we will introduce a new element: documentation. Throwing a pebble in the puddle to watch how it will ripple through. Which other elements will relate with it, and which one will not? Which transformation it will trigger in the dynamics of access, of power, and representation that are sprouting around software in each simulation?
These emerging issues will articulate the main questions of this research: could software documentation be a surface to situate code in the world? Could it be a device to foster entry points for a more diverse participation? Could it be a way to orientate technologies with our set of values?
Requirements
The first step is to decide on the participants of the simulation.
Although we could sink into a well of details to describe actors in the most accurate way, just a detail it's enough to start.
Who and what are they?
When and where are they coding?
And what do they do when they are not in front of a computer?
These and other questions will be unpacked during the simulation.
Instead, let's trace some categories: programmers, software and use cases.
These categories are a way to deal both with the software and hardware circumstances of code (Marino, 2020), but also to give space to relations with non-code entities (Mackenzie, 2006). A more-than-human and more-than-technical set of elements.
In a grey zone where Actor Network Theory (Latour) and Object Oriented Onthology (Harman) overlap, we can think to every element in these categories as an actor, or an object. Hence we can afford, on one hand, to delegate the identity of an actor to its relations with others. Here every iteration and every update of the simulation is an event, an exchange between actants. On the other hand, the unknowable nature of the object leaves room for the simulation to dig deeper, to keep renegotiating the object' state exposing different qualities from time to time.
Programmers are actors that deal with code. They will be grounded into our present and recent history, where people are often defined by what do they do in order to pay the bills. Thank you capitalism™️ for this detrimental reductionism! They are usually human (or groups of), situated within a professional context. Not all of them code for a living, but some live for coding.
Programmer
- developer
- engineer
- teacher
- musician
- artist
- designer
- researcher
- class
- student
- sailor
Software are objects made of code. Here we will refer to a particular subset of software, namely programming languages. In order to explore different worlds within the simulation we will chose languages coming from different contexts: from the present and from the past, high and low level, commercial and esoteric.
Software
- javascript
- python
- haskel
- redstone
- assembly
- cobol
- lisp
Use cases are fields or objectives one could use code for. This could seem a bit loose, but in the scope of the simulation, it orientates actors in certain directions. Their effect is more like a magnetic force, than the call of destiny. This writing machine is not an hard coded teleological device, but rather a sandbox to generate narratives around software.
Use case
- business
- work
- accessibility
- survival
- publishing
- play
- writing
- modding
- research
Setup
Notes:
-
possible references to build the dataset
- Weathering Software Winter (100R)
- Close to the Machine, Life in Code (Ulman) ch. Close to the mainframe?
- Pattern of Software, (Gabriel) ch. into the ground?
- Red Stone Focus? Mods, Essay, Virtual Minecraft, Redstone Assembly Specs
- P5js accessibility issues?
- Paged.js?
- Screenless Office
- SI16
Now we need to combine thigs from the three categories.
- developer, cobol, work
- sailor, assembly, survival
- teacher, lisp, business
- artist, javascript, accessibility
- designer, javascript, publishing
- class, python, publishing
- engineer, python, art
- artist, red stone, writing
- hacker, red stone, modding
- engineer, red stone, research
Itearate
DISCLAIMER: from here on basically just notes for the next steps of the simulation!
Notes:
-
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
-
Discrete Temporality
-
Temporality could also be a way to explore events of the past
not every simulation must be set in the presentie: 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: updating using commits in a version control system, gradually fading away when a project stops being maintained
-
-
Suspension of Judgement
-
exploration of margins
uncommon or absurd setup
why are they absurd?
what is the norm? -
proxy exploration
exploring thing we dont understand
software as unknown?ie: esolangs
-
a way to investigate and build on disproportion of means:
ie: contemporary infrastracture to code a TODOs app
ie: quest for frugality in permacomputing projects
-
-
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 refering to the overflowing of internet into real life (and the other way around)
but also expanded by modders to build different red stone dialects, forking the original oneie reclaimed technology
tech deployed for military purposes recontextualized for medical uses
(find exact references maybe in ways of being) (bridle)
-
-
Orientation
-
level of details
-
zoom out to outline trends
ie coding language hype
how languages get popular and then forgotten
trending on yt, threads on twitter, conferences, investors! sponsor! etc.less about single characters
more about their surroundings
online communities!
- When things are vivid enough go on
Now that the setup is done, the process can start. Every iteration will pose a question to the elements
To build something meaningful out of these initial combinations we can balance between what is defined and what is not. Leveraging on the unknown of the simulation gives room for narrations.
01
00
- Developer
- Cobol
- Work
01
- North american, white, young, self-taught programmer
- A business-oriented language, with an english-like syntax designed to be self-documenting and highly readable.
- an open position in a national retailing chain, for developer with experience working on mainframes.
02
- Has never written a line in COBOL.
- Ready to accept the challenge in order to get closer to the mainframe.
- It sounds like the certification of being a real developer™️.
- Program readability was a commendable design goal, and ahead of its time. But how did it come about that the main emphasis was on readability by managers, instead of readability by programmers?
- Was there any evidence at the time that managers wanted to read programs?
- Did the COBOL committee seriously believe that the users could not handle grade school operators of
+,-,x,/? - (Sannet, 1981)
- The company's processing center is on the ninth floor of a large department store. An harshly lit room. Women —all Filippinas— it seems, are working heads down, at keypunch machine. Data entry with keypunch instead of computer system at a terminal?
- Data entry systems change, bad habits and exploitation don't.
- Workers Leaving the Googleplex, 2011
03
- Haunted by the fear of getting caught as being stupid.
- Coming to a new system and not knowing how to log-on.
- Lie low and learn the basics.
04
Sailor, assembly, survival
- sailor, assembly, survival
- teacher, lisp, business
- artist, javascript, accessibility
- designer, javascript, publishing
- class, python, publishing
- engineer, python, art
- artist, red stone, writing
- hacker, red stone, modding
- engineer, red stone, research
Enter documentation
Notes:
- 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
- articulate critical points
Wrap up
Notes:
-
software as a mean to orientate narratives
-
narratives as a mean to orientate software
-
documentation as a surface to explore
-
how to situate our use of code in the world
-
which context ? situated software
-
why it matters for me!!!!!