Threads.
In this report I will reflect upon textural metaphor in computing, network as netting, and the grace of functions. I will consider where these ideas meet and what happens in this meeting. I will use a couple of recent projects I have worked on in the past year as a cast-on into these ideas and attempt to understand something about the environment we live in.
produced by: Isaac Clarke
“An ancient metaphor: thought is a thread, and the raconteur is a spinner of yarns - but the true storyteller, the poet, is a weaver. The scribes made this old and audible abstraction into a new and visible fact. After long practice, their work took on such an even, flexible texture that they called the written pager a textus, which means cloth.”
-Robert Bringhurst, The Elements of Typographic Style [1]
Recently I have been reflecting upon the work I have made over the past few months, looking for the threads running between projects and assignments, in an attempt to tie up loose ends and see the forms of my thoughts. I have found myself caught up in textural metaphor that exists in computing.
We work with pattern making machines, our computers using a form of logic not far from the looms that were their previous technological form. We layer up these patterns in various arrangements with some becoming so complex we could wait many lifetimes to see them repeat. On top of these switches we build languages that extend the material language into mental models that we use to structure our databases and manage our own movement, they reflect back to us how we think (or how we think we think). We continue to talk about processor threads, interlaced video, meshes, and net-works. I have been wondering what the constraints of this language are and if it is something to be embraced or resisted. Should my programming mimic the processes of spinning and weaving and manipulating threads, are these processes wound so tightly into the machines that they can’t be escaped?
I have found that my approach to making computational art is to make tools with which I can play. When you write a program, you write instructions of what you want to happen. I find this makes it very difficult to stumble upon something that is novel. Making tools pushes you back a layer, where you can then play and find unexpected relationships and translations. I have observed other artists using this approach too such as the unity tools developed by Fernando Ramallo [2] for David Kanaga’s Oikospiel [3], which allowed him to play his game into its final form rather than programming it.
(Below: Kanaga's Unity Tools for Oikospiel)
I have taken this idea over the past few months and created a couple of tools which have been helpful for me to play through understanding some of the textural metaphor of programming. These two programs are QuipuMaker and BraidLab. Quipu is a form of knot-notation mostly used by the Inca Empire [4] in the 17th century for various reasons, some known and some lost. Using a base 10 number system in combination with colour, knot direction, and thickness of cords, they were able to densely pack information into the threads. The descriptions of Quipu remind me of modern databases, with branches of information extending from each other, holding numeric references to physical events and objects. QuipuMaker [5] is a program which takes a text file as input and outputs a diagram for knotting a quipu, as a way of giving data a closer physical form, to be held in your hand and turned over, referenced, and counted. Like a cross between a rosary and an abacus.
The second program, BraidLab [6], was developed to create 3D models of braids. I used tiled diagrams of crossings as the cells for a version of Conway’s Game of Life[7], this gave me a way of combining functional and emergent processes, the result is a structure made from the paths of cellular movement. Entangled threads of logical locomotion.
Both of these programs offered me ways of understanding and interpreting the relationship notation has to physical form. That final form they both have is stillness, it is a memory, it is a fixed state. This is in contrast to the programs themselves which are in motion, the code is paths to follow that bring me closer to the thing I am wanting to look at. I have found that these tools of translation I have been working on have become more interesting than their output. They speak in their operation, performing the formation of returning their values.
This raises questions about the structure of the code itself. Is it a script or a score? Is my feeling that the code performs itself accurate? If I was to create a program that gave the same output but using a different programming paradigm, a different underlying structure, then would I feel differently about the program? I could see how a functional program, with fixed state, could appear more score-like than an object-oriented program. Do these paradigms offer different affective qualities to the programmer?
In his book Speculative Grace (2013) [8] the theologian Adam Miller tasks himself with “porting” grace into an “object-oriented theology”. Miller asks himself “can grace survive such a port? Would it remain recognizable? Would it still be functional?”(Miller, 2013, p.5). I began thinking of my programs and code with Millers questions in mind. I am interested in seeing how the program may hold other things than what I have coded, what qualities they may have entwined within them that have been left as traces of the network. BraidLab and Quipu Maker can be seen as tools of translation, from ASCII text to Knots and from cell growth pattern to Braids. With reference to actor-network theory Miller talks about translation and how we align objects to one another:
“Translation is necessary because objects resist transparent reduction. Translation is possible because objects, composed of and shaped by other objects, are available. Because objects resist, detours are required. Because objects are available, intimacy is unavoidable”. (Miller, 2013, p.59)
I have found this term intimate detour an effective way of describing what is happening in artworks and perhaps it also follows into the code itself. There are things that are indescribable, and we attempt to describe them. There are thoughts with no form that we sculpt. Miller comes to define grace as having two faces; of work and suffering. He goes on to suggest all objects have properties of resistance and availability which determine their presence and their interaction with other objects. It is in this presence of objects amongst objects that grace can be placed.
Thinking of Millers suggestions are we able to find grace in a program? Could we analyse the resistance and availability of a function? What would that look like?
I suggest we begin our search here, in the first line, at the arguments for the function. Here we are told what the function needs in order for it to run. If we call upon the function without these values it will resist us, acceptable arguments of the correct type allow the other lines to be read/executed/acted/performed. The program suffers the work in the material exchange happening hidden down in the threads of processing and memory. Code can be direct, or the code itself can detour. It may loop inside itself recursively or take a longer path to the same solution. In our un-optimised structures extra work is done, burdens carried, decisions made, and memories stored. It seems that the code could be full of grace.
As well as asking for something to happen the code can listen for events and it can respond to changes in its environment. It is happening now as I write, I press down on a switch and a letter is pushed through layers of operations and placed into this string. It seems as though there is no beginning or end, it is there waiting, listening. But code can only hear what it knows about. It can only hear certain sounds of certain types. It can only respond to accepted arguments. It appears that code doesn’t improvise but follows the script/score exactly. Code isn’t an intermediary as it impacts events so it should not be ignored, but the outputs are often predictable. Code has a role in handling memory that is important to the network. When a program runs it decided what to keep and what to replace, it brings processes to an end as it initialises new action.
In the essay Bringing Things to Life: Creative Entanglements in a World of Materials (2010)[9], Tim Ingold offers an alternate translation of actor-network from the original French acteur-réseau.
“But réseau can refer as well to netting as to network – to woven fabric, the tracery of lace, the plexus of the nervous system or the web of the spider.”(Ingold, 2010, p.12)
This suggestions of taking a different translation has the impact of changing how we might imagine the connections between actors. The network turned into netting allows it to be seen as “lines of becoming” and “conditions of possibility”. The image of network “goes from point to point, in sequence, as quickly as possible, and in principle in no time at all, for every successive destination is already fixed prior to setting out”(Ingold, 2007, p.75)[10] It is an articulated body, it is in its final form and like the output of a program it is still, it is only memory, it has been executed. Losing that image of straight lines connected to static nodes, and replacing it with paths of possible movement, the acteur-réseau comes alive and it becomes environment.
(below: a diagram of a social network from the wikipedia page on actor-network theory and my diagrams comparing a static memory of a network, and a netting/knotting of paths in an environment.)
Programming promises death. It promises execution. It suffers the environment and works to completion. Often, when we look at the code we look at the results, the output. You can scan your Wi-Fi network for other devices and it will return a list, a snapshot of the current state of things. So it makes sense that we often visualise these networks as an imprint of one state in time. It is useful to pause and look at where things were and how they related at that point in time, too see the connections that had been made. Trying to analyse something in motion is very difficult, you have to slow it down, make a camera that can capture the horse running past before you can see what is happening. The trouble with that is we might start to imagine that the stillness is the network we are living in, we might start to behave like the straight lines between articulated points because that is what we see. But our environment is in motion, it is braided, woven, flowing. In Lines: A Brief History (2007)[10] Ingold begins a taxonomy of lines: threads, traces, cuts, cracks, creases, and ghostly line. Ingold describes how life happens along these different types of lines. I was interested in how he described coming to this theory of lines “I had been perplexed by a particular problem that, on the face of it, has nothing to do with lines at all. It was the problem of how we have come to distinguish between speech and song.”(Ingold, 2007, p.1) This seems related to the questions I had about code. It would seem to Ingolds theory that code is notation, like a musical score.
In Wendy Chun’s essay Crisis, Crisis, Crisis, or Sovereignty and Networks (2011)[11] she discusses the separation of source code from machine code, and the blurred definitions, like those I have been making throughout this essay, between the written code and the interpretation of it.
“These definitions, which treat programs and procedures interchangeably, erase the difference between human readable code, its machine readable interpretation, and its execution. The implication is thus: execution does not matter like in conceptual art, it is a perfunctory affair; what really matters is the source code.” (Chun, 2011, p.100)
Chun discusses how code claims to be the only language that does what it says, which simultaneously denies that other language is active in the physical world. She continues showing how perhaps it is more judicial and bureaucratic, more like law, and that there is a distance between the text and the action. We rely on compilers to take our high-level code down to machine language, and we don’t really know that the processes we laid out above continue to happen in the manner we proposed. Added to this we can see how viruses can work their way into operations in the lower-levels and the assumptions of the code being performed as written cannot be relied upon. Chun discusses the constant decision making, the committing to memory and discarding of information in the machine and in the network. She asks what is saved and what is cared for and suggests that understanding code and network in this way should prompt “constant ethical encounters between self and other.” (Chun, 2011, p.107)
In Miller’s porting of grace, he emphasises the weaving together of all objects. “Our liberation is interwoven with the fate of these adopted objects. We cannot be saved without them, nor they without us, because they are the stuff we’re made of.”(Miller, 2013, p.153) Ingold opposes the object-oriented approach but talks of similar sounding leaky things. “I want to suggest that it is not just the mind that leaks, but things in general. And they do so along the paths we follow as we trace the flows of materials in the environment without objects.”(Ingold, 2010, p.13) And while Chun sees the digital as an event not a thing, the repetition it insists upon for its presence seems to fit with the idea of a netting of paths. “It also forces us to engage with the fact that if something stays in place, it is not because things are unchanging and unchangeable, but rather because they are constantly implemented and enforced.”(Chun, 2011, p.106)
It seems as though there is a concern that runs across these different writers (Miller, Ingold, and Chun) which I would identify as a concern with the visibility and representation of state. Variables are overwritten with new values. We can suggest when this happens in our code, but we don’t know when this act happens. Computers continually shift form, moving along paths of being, physically working, to insist to us that it is present. Much of this insistence returning snapshots of stillness. It could be that functional programming, with a refusal of variable state, could offer systems with a clearer memory. Imperative or Declarative programming would still have a shared problem of how we make clear the paths that the data moves through, how do we visualise state in ways that aren’t static misrepresentations of relationships and also aren’t lost in the complexity of interwoven threads.
There are interesting projects emerging attempting to tackle visibility of state such as Bret Victor and Alan Kays project DynamicLand (2017)[12]. With this visibility of how a machine is “thinking” we will be able to better care for networks and our environments. Being able to “follow the flow”(Victor, 2012) will allow us to “create by reacting…create by abstracting”. If we can see the state, we can see the connections.
“There is something in common … between the way in which words are inscribed on a page of writing, and the way in which the movements and rhythms of human and non-human activity are registered in lived space, but only if we think of writing not as a verbal composition but as a tissue of lines – not as text but as texture.”(Ingold, 2010, p.11)
I would encourage using the language of weaving in computing as it breaks us away from static representations of data. The motion of threads pulling together helps us see our connections as always evolving. Netting and Knotting bring us to place our computing physically. Textural computing can be useful for understanding ways of connecting ourselves, our machines, and our shared environment.
------------------------------------------
REFERENCES
[1] Bringhurst, R (1992) The Elements of Typographic Style. Hartley & Marks.
[2] Ramallo, F (2017) Oikispiel Tools. Available at: https://unitylist.com/p/me/oikospiel-tools. [Accessed 9 May 2018].
[3] Kanaga, D (2017) Oikospiel: A Dog Opera. Video Game.
[4] Ascher, M. Ascher, R (1982) Mathematics of the Incas, Code of the Quipu. Dover Publications Inc.
[5] Isaac Clarke. 2018. Quipu Maker. Available at: https://github.com/isaac-art/quipuMaker [Accessed 9 May 2018]
[6] Isaac Clarke. 2018. BraidLab. Available at: https://github.com/isaac-art/BraidLab [Accessed 9 May 2018]
[7] Gardner, M (1970) Mathematical Games: The fantastic combinations of John Conway's new solitaire game "life". Scientific American.
[8] Miller, A.S. (2013) Speculative Grace. Fordham University Press.
[9] Ingold, T (2010) Bringing Things to Life: Creative Entanglements in a World of Materials.
[10] Ingold, T (2007) Lines: A Brief History. Routledge Classics.
[11] Chun, W.H.K (2011) Crisis, Crisis, Crisis, or Sovereignty and Networks in Theory, Culture & Society. Sage.
[12] Victor, B. Kay, A (2017) DynamicLand. Available at: https://dynamicland.org/ [Accessed 9 May 2018]
[13] Victor, B (2012) Learnable Programming. Available at: http://worrydream.com/LearnableProgramming/ [Accessed 9 May 2018]