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.
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 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.
- a way to present how the hype for a particular coding language grows
- ie: list of trending video on yt, threads on twitter, conferences
- how languages get popular and then forgotten
- how these istogram video of language popularity are done ? find sources
- temporality could also be a way to explore events of the past
- not every simulation must be set in the present
- (or rewinding back simulating causes instead of effects)
- ie: Ulman account on childish developers culture (Close to the machine, Life in code)
- ie: Richard Gabriel timeline for example (Pattern of software)
- Temporality could also be non uniform!
- ie: using the timespan of new commits in a version control system, gradually fading away when a project stops being maintained
- Could be interesting to read What the Dormouse Said
- Suspension of Judgement
- exploration of margins, fy shuffle and normal distribution
- uncommon or absurd setup (why are they absurd?) (what is the norm?)
- meta exploration: or exploring thing we dont understand (software as unknown?) (like esolangs)
- a way to investigate and build on disproportion of means:
- ie: all the js of react + all the css of tailwind + all the backend infrastracture of netlify to run a TODO list
- ie: the extreme quest for frugality in permacomputing projects such as 100R or DuskOS
- is not redemption arc for bad guys
- Partiality
- (that could also be read as multiplicity)
- focus on the same actor in different contexts:
- ie redstone circuits
- used to develop a virtual minecraft into minecraft itself
- but also cited by hito steyerl when talking about the overflowing of internet into real life, as well as the sinking of real life into internet
- but also expanded by modders to build different red stone dialects, forking the original one
- another example is:
- reclaimed technology
- tech deployed for military purposes recontextualized for medical uses (find exact references look at software studies lexicon or bridle ! ways of being)
- Orientation
- level of details
- zoom out to outline trends
- less about single characters
- more about their surroundings
- online communities! investors! sponsor! etc.
- and then zoom in for wrapping up
- ideally: to a distance within reach ? is this naive?
- structure
- other than these four features of the simulation there should be a structure
- with a clear structure the simulation can be more heterogeneous
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
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?