@ -41,7 +41,8 @@ Using the simulation as a writing machine we can articulate these CC with some b
- Partiality
Partecipants entangle gradually, and do not come as a monolithic block.
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.
@ -89,27 +90,33 @@ The simulation is structured as a series of stages:
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 and setup
## Requirements
Notes:
- not only
- the software and hardware circumstances of code (Marino, 2020)
- but also
- the relations with _non-code entities_ (Mackenzie, 2006)
- 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
@ -120,6 +127,31 @@ Notes:
---
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.
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.
Instead, let's trace some categories: programmers, programming languages and use cases.
These categories are a way to deal both with the software and hardware circumstances of code (Marino, 2020), but also their relations with _non-code entities_ (Mackenzie, 2006). A more-than-human and more-than-technical set of elements.
<!-- 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.
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.
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.
- actors
- web designer
@ -149,6 +181,8 @@ Notes:
- activism
- survival
# Setup
then we need to combine thigs from the three categories
0. web designer, rust, activism
@ -162,19 +196,6 @@ then we need to combine thigs from the three categories
8. student, javascript, fun
9. graphic designer, haskel, research
...
side note
the first in a series
NOT is the series on theory in italian by NERO editions
their first pubblication was Capitalist Realism, Mark Fisher and it was a declaration of intents.
at some point every first is a declaration of intents.
but is that so also in random generated series?
at first one is tempted to write: no
the random generated series is random, and its first element is random as every other.
but taking a step back, zooming out, one wonders: which element is the first? where is the declaration of intents?
could the command that generate the random series be the first, significative, element of the series itself?
