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.
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.
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.
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.
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.
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?
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.
_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.
_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.
- 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`, `/`?
- 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.
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?
