In Critical Inquiry‘s most recently published issue (Vol. 39 No. 2, Winter 2013), Alexander Galloway has an essay entitled, “The Poverty of Philosophy: Realism and Post-Fordism”. Here, I mostly want to walk through some of the programming practices that Galloway is describing when he talks about object-oriented programming. I am a beginner to programming, but I believe I know enough to illustrate his ideas.
In my limited experience with programming, I’ve worked mostly with Java and Python. I’d say I know Python better, so I will use that to demonstrate some of the programming Galloway is talking about in this essay, as Python is also object-oriented. Python’s readability will also help in this regard.
Galloway starts with a comparison of Alain Badiou’s philosophy and the computer programming language Java, specifically the concept of inheritance in programming. Galloway’s goal is stated: “I wish instead to compare Badiou’s two basic terms to a related set of concepts found in the specifications for Java, a popular object-oriented language developed as one of the first platform-independent programming languages” (350). He goes on to describe membership which involves inheritance: “Object-oriented languages are organized around the concept of a class or an abstract description of a module of code, which can be instantiated into an actually existing class instance known as an object. Membership refers to the data structure that composes the object. An object’s members can include variables, methods, and other declarations. The members can be declared directly within the class, or they can come from members of a parent class for which the object is a child” (350-351). I can show you this idea using Python code:
Above in Fig. 1, we see an example of inheritance. In lines 1-3, the class Parent is defined. [For this example, we don’t need to talk about the reason “object” is included in parentheses after “Parent” on line 1.] The use of indentation in lines 2 and 3 are essential for Python to understand this code kind of belongs to the code above it. So in line 2, “def function_of_parent(self):” is basically saying, “I am defining the function [also known as a method in other languages]. This function is called ‘function_of_parent.'” A function can simply be described as an instruction that should be fulfilled. The instruction here is on line 3, where it is told to print the string of characters, “Hello World, from the Parent”. So quickly in summary, we have a function defined within the class Parent.
In lines 6-7, we define a new class called “Child”. On line 6, after “Child”, we have “(Parent)”. It is by putting the name of a previously defined class—”Parent”—into the parentheses following “Child”, that we say that the class Child is a child of the class Parent [I should clarify that the capitalized “Child” or “Parent” is the name of the class, and the lowercase “child” or “parent” is the type of class being described]. In other words, the class Child now has inherited the attributes of the class Parent, including that function we defined earlier, function_of_parent. On line 6, we have “pass”, which simply tells the computer that there’s we’re not giving any more stuff to Child (besides, of course, all of Parent’s attributes). We could also have the class Child written like the following if you want it to have its own attributes like a new function:
In Fig. 2 above, the class Child still inherits attributes from Parent, but now it also has its own function particular to itself.
Galloway is talking about this type of inheritance (which in Java can be called extension), when he writes, “Such parent-child relationships designate the second aspect of Java pertinent to the present discussion: inheritance. Through a process known as extension, classes can extend other classes, meaning they inherit all (or some) of the qualities of that class. In common parlance the class being inherited is called the parent class or superclass, and the class doing the inheriting is called the child or subclass” (351). So for the code above, Parent, defined on line 1, is the parent class, and Child, defined on line 6, is the child class.
Galloway goes on to give an example: “Thus consider the following hypothetical relationship of nested classes and superclasses: a class defined as red apple could also be defined as an extension of a superclass apple, inheriting all the qualities of the superclass, and the superclass itself could be defined as an extension of a still higher class, say piece of fruit, and thus both apple and red apple would inherit the qualities of piece of fruit, both being downstream from it” (351).
Let’s translate that into code:
In Fig. 3, above, we see on line 11, that class Red_apple inherits attributes from class Apple on line 6, which inherits attributes from class Piece_of_fruit on line 1.
The instantiation that Galloway mentioned when he said that a class “can be instantiated into an actually existing class instance known as an object” can also be shown. Here, I’ll continue with Galloway’s example of fruit and apples. Let’s make an object out of this abstract bit of code and inherited attributes known as “class Red_apple”. We can name the instantiated form whatever we wish, so let’s say we want to define it as a tasty red apple. We would add the following bit of code to the end of the code in Fig. 3:
Now, we have the object “tasty_red_apple” made from instantiating the class “Red_apple”. Because of the inheritances that Red_apple had, tasty_red_apple has all of the attributes of Red_apple in addition to those of Apple, and thus Piece_of_fruit. So we could call a function from tasty_red_apple that it inherited all the way back from the class Piece_of_fruit, like so:
In Fig. 5 above, we see that the function “fruit_quality” from the class Piece_of_fruit is successfully called as an attribute of tasty_red_apple, resulting in the string “I am a piece of fruit.” being printed to the screen in the next line. Of course, functions from both the class Apple and the class Red_apple can also be called from tasty_red_apple.
Now, having walked through some of these ideas of inheritance in object oriented programming, let’s move on to Galloway’s assessment of a similarity he finds in Badiou’s concept of belonging: “In short the logics of belonging and inclusion that structure Badiou’s ontology are identical to the logics of membership and inheritance that structure today’s object-oriented computer languages” (351). Having not read enough Badiou, I can’t say whether this is correct. Galloway continues, “As I have already hinted, the conclusions to be drawn from all of this are somewhat disconcerting. Such object-oriented computer languages are themselves the heart and soul of the information economy, which if it is not synonymous with today’s mode of production is certainly intimately intertwined with it” (351). This is the part that I’m not so sure about. Computer languages aren’t the heart and soul of the information economy. Capitalism is. It should also be mentioned here that the object-oriented paradigm of programming is not the only one. Of course Java is used by business, but I just don’t see a programming paradigm as essentially complicit in capitalism for the last few decades. To the extent that tools change our perceptions of ourselves and the world, however, is up for debate, and is something worth looking into, with regard to software.
There are parts, however, where Galloway recognizes that mere similarity or connection is not assigning something like Badiou’s use of set theory as a tool of capitalism: “Granted, merely identifying a formal congruity is not damning in itself. There are any number of structures that ‘look like’ other structures” (352).
The thing about programming that seems important here is that it is able to handle enormous sets of data, and process them in whatever way a programmer wishes. One could say that much of the calculations that computers do could be done by hand with a pencil and some paper. The grand timescale involved in doing the comparable work that a computer does, however, shows why we use computers to do those calculations for us. Later on in the essay, Galloway writes, “A simple syllogism reveals the conclusion that the mode of production today has a special relationship to mathematics. Software is thus the thorn in the side of contemporary philosophy. As the opening remarks on Badiou and Java illustrated, there exists today a convergence between the logic of mathematical disciplines (such as computer science) and the logic of the mode of production” (357). In a footnote to this excerpt, Galloway wonders whether math has always been used in production. I would say it certainly has. Mathematics has long been a tool of the capitalist mode of production, and computers, at their basic level, are an additional tool for expediting the use of mathematics.
As far as the rest of the essay is concerned, it seems I would need to read Quentin Meillassoux’s After Finitude, among other works, to give a thorough response. Moacir P. de Sá Pereira has already made an interesting response, in which an argument is made for the uncoupling of ontology and politics, the rift between realism and materialism is pondered, and some of the differences between the thinkers of the OOO/SR group are presented. Graham Harman has also given a brief reply.