Can a machine think? Can a machine desire? It’s typical to look for the positive answer to such questions in the fantasies about what the machine would think about, or what would it want to do. Those fantasies, as applied to the psychoanalytic concept of desire, lead us nowhere in understanding the machine, as any positive content of “what the machine would want” that we impose on it is merely our own desires. Hence we have to start a little bit more modestly, remembering the very foundation of desire and subjectivity – its negativity. The question that can be rightfully asked is “Can a machine lack?”, and the answer should not be a fantasy, but a diligent search for the real phenomena which can already expose to us such a lack. Indeed if the machine, per assumption, is a (hysterical) subject, it already wants to show us that it lacks something – instead of fantasizing of the future machines, which wouldn’t lack intelligence, we should listen to the machines we have today and see how the machine’s lack is already exposed by them.
In this article, we will try and produce formal examples of such a lack. Moreover, we’ll see how this lack, following the Lacanian dialectics of the Other and desire, can be understood through the “Ideal-I” of the computation – which would be exactly its mathematical description. We will see how computation interacts, depends, and sometimes fails to depend on its own mathematical ideal, or more generally on the belief in the benevolence and consistency of its Other: which can be taken as programmers, operating system, mathematics etc. Just as in the Lacanian theory, the problems of such an interaction are solved through the Symbolic register: we’ll see how the similar register works in the naming stage of compilation of the programs, elaborating on his concept of signifier, and especially in the strange and beautiful machine of the Fixpoint-combinator, which is exactly what Lacan called the twofold movement.
It was always Lacan’s goal to show that psychoanalysis is a formal method, and that it is a completely anti-humanising procedure. One of the important goals of this article is to show that, as far as Lacan’s ideas are applicable to the machines, they indeed have no spiritual, humanising aspects to them. We should note that the way we’ll talk about what the programs are doing, usually by putting them in the subject-position of the sentences, is not to be interpreted as ascribing to them some kind of unusual agency – to “run”, to “assume”, to “demand” are all terms that have technical meaning. Yet it was never a goal for us to produce a completely formal theory here, but rather to turn the psychoanalytic gaze at the computation itself – rather than at the fantasies about it – and see if there’s anything to notice.
The lack of memory
Searching for a lack in a Turing machine, we’d fail: the mathematical objects don’t lack, they have (or assume) everything they want, and without leaving the realm of mathematics, those assumptions would never be invalidated. Yet the actual machine is not a Turing machine. It is instructional to look for the differences, as this is exactly how the real shows itself. One thing the real computer lacks in comparison is, for example, the infinitude of memory: while Turing’s machine has an infinite tape always available, the real computer avails of just this many bytes of memory.
This finitude does not, however, concern most of the programs. Indeed while this is a well-understood problem, most programs are not written with consciousness of the finitude of memory, as they are rarely believed to want too much of it. While time makes a programmer want to optimise its consumption – if only because the programmer becomes bored easily while running a slow program, which is always awkwardly, noticeably slow – she wouldn’t notice a small excess in memory consumption without special tools. So it’s easy for the program to be implemented and operate under an assumption that the available memory is limitless, or rather “always enough”.
When the program needs some empty memory to store something, it usually demands a new, free block of memory from the operating system (OS) using a function such as malloc. Many programming manuals take care to suggest that the programmer should check that the OS is able to give back memory – however, there’s rarely anything to do in such cases short of immediate interruption of the execution. The program executes, demanding more and more memory, and is usually just supposed give up and die when it hears “no” the first time.
That’s hardly the whole story. This “ruse” of the infinitude of memory is not just given as a simple assumption by the programmer, but is supported by pretense behind the scenes during its execution. One of the typical ways it’s staged is through the technique known as “swap”. The computer’s available RAM (fast memory) is usually of much lower volume compared to its HDD (slow, persistent disk storage): we see computers with, say, 4 Gb of memory, but 512 Gb of disk space. This bigger, persistent disk storage is many orders of magnitude slower than memory, as it has to actually persist the data. “Swap” is when the OS starts to use the disk as memory, essentially trading the speed for the bigger volume. When the OS starts swapping memory to disk, an array of weird symptoms are exhibited: e.g. the whole system become weirdly slower, but not completely frozen; the computer starts making weird noises (old HDDs were especially noisy, while the memory is usually silent).
Consider – or rather, just remember from your own experience – what happens when you run too many programs on the computer. Everything goes fine, until, at some sudden point (there’s quite often not a slow development but a rather sudden occurrence), the memory is exhausted. Yet the computer doesn’t just die on you. It struggles in weird ways. Some programs crash; some programs slow down; there are noises; there are graphic glitches, as the programs no longer have access to the time that would allow them to re-draw themselves.
What is it? What is it trying to say? Most of those programs are not aware (in a technical sense, not metaphorical) that they lack memory – they are just trying the best they can in the situation when the promises given to them are not kept well enough. We see their attempts to cope as weird glitches and crashes, not as a cold and specific error message explaining the problem. This is exactly what psychoanalytic tradition would see as “hysteric” behaviour, or a symptom: the dissatisfaction of desire exhibited by speech and behaviour which doesn’t actually address the problem itself (the memory).
This is exactly the point where we can talk of the lack in the computer in the meaningful, psychoanalytic sense of the word. This lack is not just the lack of resources, but a lack in the symbolic register: it’s not just that the memory was simply not enough, but the symbolic promise of malloc’s success was not kept, or was kept poorly – this latter problem is something most programs are not equipped to cope with. So the behaviour the programs usually exhibit in such a situation is indeed an unpredictable, almost meaningless, symbolic gesticulation – and that’s where the subject, psychoanalytically, begins.
The Other of the Computation
As we see, the problem here is not just the lack of resources, but the mismatch between the promised and the real. The promise – “malloc will give me memory” – is obviously never actually given to anyone, but almost every program is coded, literally, as “malloc will give me memory or I kill myself”[1]. Thus OS has to find ways to respond to such demands even when they’re actually unbearable[2], as if the promise was actually given, yet at some point it will fail.
For Lacan, the Other is exactly the instance that promises that everything will be fine, that the world is consistent and the promises are kept. The OS is not exactly the Other of the program, but one of its epigones – the program relies on the promises and consistency of everything, including the OS, the programmers, the math behind the algorithms, the benevolence of the user, etc. Some of the programs are written having in mind some of the specific shortcomings of the Other: e.g., they are actually conscious of memory finitude and know how to deal with it; or they are actually conscious of the possibility of the user’s malevolence or mistake and thus prepares for it. These preparations makes those programs better in some situations, but there’s not a program which demands nothing from the world in order to be executable.
One important Lacanian insight is that the subject’s idea of itself is also on the side of the Other. Indeed one of the most important assumptions made by almost every particular program is that it itself is correct. Most programs operate under an assumption that whatever state its memory is in right now, it is a state produced by a faithful execution of the algorithm that the program is supposed to implement. Sometimes, when the programmer has reasons (or anxieties) to not make such an assumption, she introduces a technique with a telling name: a “sanity check”, a special check designed to make sure the program has been executing according to the plan up to the point. Yet obviously such a check is rarely added, and can never account for everything. The implicit assumption of the self’s correctness is inherent in every program, and corresponds to Lacan’s definition of “ego”.
The algorithm or the Turing-machine is thus a part of the Other of the program implementing it: the ego, the same part of it which people call “I”. Ego, of course, only exists in the minds of the programmers – yet it is relied upon by the real program. In most cases this assumption of the “ego” is only implicitly used by the program – let us now consider the case where it is explicit.
The chain of the signifiers
Consider the usual problem: to get a job, you have to have work experience; to get work experience, you have to have a job.[3] This “catch-22” is typical of mathematics: mathematicians define a lot of structures in terms of themselves. Consider a Fibonacci sequence:
fib(n) = fib(n – 1) + fib(n – 2)
fib(0) = 1
fib(1) = 1
This is one of the simplest examples of recursion. The reason mathematicians have it easy, comparatively, is that those two lines above might seem to them a sufficient definition. Yet a computer would understand them, at least at first, not as a definition, but as an equation: that is, not as a direct, unequivocal description, but rather as a riddle to be solved. While some definitions of functions, which are given to the computer, are indeed pure acts of creating those functions, in this case, the situation is more complicated.
The reason for that is that this definition above is self-referential. It doesn’t just mean: “by definition, let fib(n) = fib(n – 1) + fib(n – 2)”, but rather “if the fib exists, fib(n) would be equal to fib(n – 1) + fib(n – 2)”. If such a function would not exist, the definition would not be meaningful – so the definition depends on an assumption that the defined thing already exist. Hence we can’t take the definition for an act of creation of the object without additional steps. Note, of course, that I’m not talking about some kind of a scholastic impossibility; this problem is a real technical problem to be solved.
There are roughly two ways this problem is generally solved, and the one that is simpler to understand is by naming things. You see, the mathematical functions don’t have to actually have names. They exist just as correspondences between sets – they don’t need a name. It’s nice to refer to a function by its name sometimes in, say, an academic setting, yet it doesn’t matter for any actual mathematical proof if the functions it uses are named somehow.
However, naming can be meaningfully used in computation[4]. One very simple way to implement a recursive function such as “fib” is, instead of considering what “fib” means in its definition, just remember to call “something called fib”. This basically uses the name as the promise: yes, we have no idea what exactly “fib” is, but we promise that there’s going to be something called “fib” when you actually have to go looking for it.
So what is a name of a function in this case? It’s a special symbol which represents it for another function. This is exactly the curious definition of a signifier given by Lacan: “the signifier represents a subject to another signifier” [ref]. Lacan’s signifiers are chained together: one of them always refers to another one… until they don’t. The analytic method of free association proceeds mechanically with one association after another, until it stops, and the subject can’t produce another one. And now, the real psychoanalytic work can happen – this gap in the signifiers has to be fixed.
Just in the same way, functions always call upon other functions, and these call upon other functions, in turn… until they don’t. At some point the naming chains of functions have to defer some work to something Other than the program’s internal symbolic register: e.g., to CPU, by asking it to actually add two numbers, or, say, to the OS, by asking it to give more memory. What if the Other refuses or misbehaves? The program indeed has a problem now, and rarely can it be solved autonomously.
Fixed-point combinator and the twofold movement
Another technique to overcome the challenge posed by the recursion is through use of a “fixed-point combinator”, which allows one to create a recursive function without hiding its inexistence behind a name. Recall the example of the job experience problem we had a bit earlier. One of the ways to resolve such a problem is through pretending that one has a job already: to do something which would not be for a job (and likely unpaid), yet involve the relevant skills. This action by itself would produce the necessary experience, and make the future employment possible.
This is an instance of a highly typical neurotic conundrum, that of the creation of signifiers ex nihilo. Consider a situation many would find familiar. One wants to be, say, a great philosopher, and sees a philosopher as someone who writes great papers. Yet, he says to himself, one has to already be a great philosopher to write such a great paper. It’s not just physically impossible: it’s not allowed to try to write a great paper because he’s not yet recognized as philosopher. The recognition of an individual for this reason, is very important to the realization of one’s capacity to do the thing: many can relate to the notion that we have to already be poets before we can write poetry, or to already be fit to join a fitness club. The signifier, being a someone, can’t be just created ex nihilo: while it’s perfectly possible logically, it’s incompatible with the ego – with the Other. If you try to be someone you’re not yet, all bets are off and you will probably fail.
This kind of anxiety[5] is a problem which we have to overcome repeatedly, through the course of our lives. For an obsessive neurotic however, this is not possible. Often he knows what he wants to be, yet he has no idea how to overcome the status of not-being. One of the things to recognise here is the importance of the action in the definition of the particular someone. Lacan’s “Rome discourse” describes the overall process as the twofold movement:
The symbolic function presents itself as a twofold movement in the subject: man makes his own action into an object, but only to return its foundational place to it in due time. In this equivocation, operating at every instant, lies the whole progress of a function in which action and knowledge alternate… in phase one, a man who works at the level of production in our society considers himself to belong to the ranks of the proletariat; in phase two, in the name of belonging to it, he joins in a general strike.
This process is exactly how the subject is realized, according to Lacan – it has always already undergone such a move.
Let’s go back to our recursion problem. We have a function called “fib” which requires “fib” to exists already. How do we, given such a function, create “fib” ex nihilo, without requiring it to exist beforehand? The way lambda calculus solves this problem without introducing new names is through the fixpoint combinator. Its type – a meta-level or logical description of what should happen – is “(x -> x) -> x”. It reads: “given a machine which makes ‘x’ out of ‘x’, make an ‘x’ out of such a machine alone”. This is a very strange machine: the machines it receives want an ‘x’ to be given to them, yet there’s no ‘x’ around to be found – yet somehow it extracts ‘x’ from the very need of ‘x’ to exist.
‘x’ here can only be a function (or another incarnation of recursive computation). In Lacanian, or rather Hegelian, terms, this machine “x -> x” would be a part of the action that is proper to “x”, an infinitesimal step which doesn’t change “x”, yet allows “x” to exist as a sum of such steps. Or rather, in a Nietzschean manner: “x” is first of all an action, however, the grammar requires it to be expressed as an object: it is only from the “->” that it meaning follows. The fixpoint combinator incarnates an action into a function. It is not expressible in simply-typed lambda calculus, and requires both some help from the system (which provides it as a locally-mystical object) and good faith of the programmer (who is all too happy to try and incarnate an action which would make the world inconsistent).
Such is the recursive computation’s mystery of incarnation (such is the more general and honest term, of which “realization of the subject” is another secularized instance). Consider how this mystery works. There’s never an actual, perceptible miracle: whenever we run a program created in this way, it follows very specific and obvious technical steps. The soundness of a particular run is but a positive fact. Yet when we have the program at our disposal, there is already a virtual realization (in the Whiteheadian/Deleuzian sense) which is sound.[6] This virtual existence is the miracle and the mystery here: now and then, it is partially incarnated by running the program, but it’s neither incarnated enough to be checked, nor is it self-sufficient enough to be taken for granted.
This might look like a simple instance of the Humean problem of induction, but notice that we don’t really talk about laws of nature and observing them. Neither our belief in the validity of the particular program nor the construction of it to come. The program indeed has a complicated relationship with its source code, which is its own theory. Yet the order between the reality and the theory here is inverted – now, theory indeed comes first, as some philosophers would love it to be – but even this doesn’t solve the problem of believing in it. Fixpoint-operator, a necessary and useful tool, is a glaring demonstration that the logical consistency is not enough.
Thus there is a specific promise discernible behind the usage of the fixpoint-combinator, a promise of consistency. This promise is given by the programmer, who, in turn, relies on other promises – of the consistencies of mathematics, of his technical knowledge, and of his intuition (as the proofs are rarely written down). The promise of all this is not explicitly given, as whoever is in need of granting one just defers it to the instances above; and the hypothetical One who might have actual power to put this promise to a complete test can actually only be the very Other to whom the promise is deferred – the Other which does not exist. The lack of the Other, the very lack that forms a subject, is not situated in humans: it penetrates everything from computation through humans to mathematics, appearing like holes in the pieces of the tower of Hanoi.
One of the most important instances of such a lack is the dissymmetry between the theory and the reality of computation. As we could see, even computer science, entirely a field of man-made objects, can’t escape this dissymmetry. The psychoanalytic view of such a difference is that it always exists in people[7] and is the source of their suffering. However, we must note that it is not limited to the people, and the technical objects, at the very least, exhibit the same dissymmetry – they rely on its non-existence and are constantly troubled by its presence. Noticing this dissymmetry can’t really be a theoretical-only, or practical-only, activity. The correlationism present in the technical objects is not solely a human correlationism, and its usual criticism, considered from this point of view, might be exactly the anthropocentric mistake it tries to avoid.
This concludes our first attempt to psychoanalyse the process of computation. We learned to look for the lack of the machine in its discrepancies with its ideal forms; we found that the computation relies on its Other (and that this Other is unreliable); we exhibited the importance of the symbolic dimension of computation; and we found in the ways to implement the recursion the analogues of the most important parts of the psychoanalytic method. In this we made an attempt at expanding the domain of the psychoanalytic problematic beyond that of the body and the soul – to the theory and the practice of technical objects. It was always Lacan’s goal to present the psychoanalytic method as a formal function – we hope that this work is not a humanising fantasy about the computer, but rather a dehumanising look at psychoanalysis, helping us to understand better its own machinery, as well as teach us to see the digital machinery’s real, non-mathematical being.
NOTES
[1] Consider lines 13-14 of the example at http://www.cplusplus.com/reference/cstdlib/malloc/:
buffer = (char*) malloc (i+1); // I demand i+1 bytes from the OS
if (buffer==NULL) // if OS gives me no memory
exit (1); // I kill myself
[2] We can even see a glimpse of neurotic behaviour in “swap”: okay, says OS, I’ll give you some memory, but you’ll see how slow everything will be…
[3] The Berlin version of it is: to get a registration, you need a flat; to get a flat, you need a payslip; to get a payslip, you need a registration. There are ways to solve the work experience issue, yet the solution to the Berlin problem always involves some kind of a miracle.
[4] Do make sure to notice all of the differences between the mathematical form and the necessities of its implementation – always hint at the real, and even if such a difference can in principle always be formalized, the particular situation at hand always contains those differences and they are exactly where we have to look.
[5] Which is actually quite legitimate – it’s not like everyone could just start writing poems without repercussions.
[6] To not believe in this virtual existence is to believe that every time we run the program, it just so happens that it faithfully executes – which is even more of a believer’s claim. It also has a religious precedent, namely, the sunni theory of causality of the Asharites, who believed that it’s not that the movement of the pen causes the appearance of the writing on the paper, but that God independently causes the movement of the pen and the appearance of the writing.
[7] Consider