txt/cc.md

---
title: Coding Contingencies
---

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.

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 Code Golf 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 precise 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.

Using the simulation as a writing machine we can articulate these CC with some benefits:

1. 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.

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 characters, where not all the elements needs to interact with each other all the time. (Haraway)

4. Orientation

    Zooming in and out from the particular, we get a glimpse of a more gradient and diffuse process.
    A subtle sense of direction emerge from the initial randomness.
    (By design) the simulation sees software as a mean to orientate these trajectories.
    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.

```
------+.
|`.    | `.
| `+--+---+
|   |  |   |
+---+--+.  |
 `. | `.|
   `+------+
```

Software Contingencies
the simulation

first we need things to simulate:

-   actors
-   programming languages
-   use cases

the simplest simulation

aha how do we define actors?

it reminds me of this OOO statement:
objects sink into themselves
that is an effective and graphical way to describe technical reference pages and auto generated API specs, with nested nested nested layers of list.

to avoid that
let's define actors not for what they are but for what they do
(that is fun bc then i wrote grandma, that means functional grandma, that means not someone that has grandchildren but someone that does grandparent functions ??? ok this is not fun anymore and i am sorry)

> notes

-   expand simplest simulation: few elements, 1:1:1 relation
-   more context for the ooo statement, or keep it for later
-   the grandma joke is not super fun

-   actors

    -   web designer
    -   interaction designer
    -   graphic designer
    -   musician
    -   teacher
    -   student
    -   grandma

-   programming languages

    -   javascript
    -   python
    -   vvvv
    -   pure data
    -   haskelz
    -   rust

-   use cases
    -   research
    -   work
    -   art
    -   fun
    -   activism

then we need to combine thigs from the three categories

00 web designer, rust, activism
01 teacher, python, work
02 grandma, rust, fun
03 interaction designer, vvvv, art
04 musician, pure data, work
05 musician, haskel, research
06 student, python, art
07 student, javascript, work
08 student, javascript, fun
09 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?

now that the setup is done, the simulation can start.

to build something meaningful out of these random combinations we can balance between what is defined and what is not.
leveraging on the unknown of the simulation gives room for narrations.

so for example we have #04

```
a musician        what is their background?
                  which kind of music do they play?
                  where are they based?

using pure data   an open source visual programming language
                  works in real-time
                  focus on interaction and sound design

for work          which kind of occupation?
                  is it for interactive installations?
                  to teach sound design?
                  for live gigs?
```

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?