Coding Contingencies (CC) is a procedural take on how different characters got to 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.
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.
2. 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.
3. Partiality
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)
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.
How does certain programming languages facilitate certain ways of thinking, and totally block some others?
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.
After this overview, the simulation follows a series of steps:
1. Requirements
Where we decide and define the elements involved in the simulation.
2. 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.
2. 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.
The 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 a world is iterated, the more in depth its simulation becomes.
```
loop through worlds
for each world
visit each participant
ask for update
```
3. Insert documentation element
Throughout some iterations, the worlds will develop network of relations between actors.
see how there are a lot of open questions in the first and third fields, while the programming language is slightly more defined and fixed. this is a good starting point. obviously a programming language is vast and complex and with dozen of features one could be interested in, but for the sake of our system it is useful to leave these things unsaid.
we can use the software as a pivot to orientate the relation between the actor and their intentions.
from where they are coming and where do they want to go?
who took them there?
what do they need?
which particular aspect of pure data resonates with their view of the world?
is it the open source nature and the licensing of the source code?
the welcoming community thriving around the programming language?
or the visual paradigm that facilitates the thinking about and connecting abstractions together?
