This introduction is not a written as a text, but runs a simulation.
Coding Contingencies (CC) is a procedural take on how different characters got to code.
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.
@ -92,49 +92,14 @@ The simulation is structured as a series of stages:
## Requirements
Notes:
- possible references to build the dataset
- Weathering Software Winter (100R)
artist, assembly, survival
- Close to the Machine, Life in Code (Ulman) (focus on episode)
developer, cobol, accounting
- Pattern of Software, (Gabriel) (focus on episode)
philosopher, lisp, sell
- Red Stone Focus?
artist, red stone, writing
student, red stone, modding
engineer, red stone, research
- P5js accessibility issues?
- Paged.js?
collective, javascript, desktop publishing
- Screenless Office?
developer, python, art
- Tidal Cycles?
musician, haskel, play
- Python and diataxis?
- SI16?
class, python, publishing
- Generate data
- Actors
- Programming languages
(brief overview?)
- Use cases
---
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 precise way, in a simulation just a detail it's enough to start.
Although we could sink into a well of details to describe actors in the most accurate way, in a simulation 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 unpack during the simulation, in a plastic way.
These and other questions will be unpacked during the simulation.
Instead, let's trace some categories: programmers, programming languages and use cases.
@ -142,59 +107,86 @@ These categories are a way to deal both with the software and hardware circumsta
<!-- TODO: im not sure about the next paragraph -->
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 drastic reductionism! They are usually human (or groups of), situated within a professional context. For not all of them programming is a job though.
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 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, esoteric and forgotten.
```
Software
- lisp
- cobol
- javascript
- python
- haskel
- assembly
- redstone
```
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.
- 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](https://www.minecraftforum.net/forums/search?display-type=1&forum-scope=t&page=4&search=redstone%20mod&search-type=0&sort=-commentcount&submit=y), [Essay](https://www.e-flux.com/journal/49/60004/too-much-world-is-the-internet-dead/), [Virtual machines]()
