Object-oriented ontology, or programming's creative fold

Click to increase image sizeClick to decrease image size

Notes

1. In addition to coding, there is another significant task in software engineering: design. Other arts combine design and execution, opening a dialog whose tensions inspire creative solutions by presenting to the artist unanticipated problems. Programming minimizes this dialog, in part by separating bureaucratically the two aspects of software engineering, design and execution. At the core of Brooks's argument is the melding of these two, as he locates the irreducible labor of programming primarily in the design of code complex enough to accommodate complex situations.

2. Readers may recognize the Deleuzian heritage of this concept of creative desire.

3. Technically, some parts of this translation are not compiling, but are related processes: linking, assembling, pre-compiling, parsing. Compiling is the bulk of the process, however, and I refer to it here metonymically, in keeping with common usage.

4. Friedrich Kittler marvels at the magic of this invocation, wherein to type a name or click a mouse is to set in motion myriad essential processes: the way the computer understands language. Note also that some computer language systems are not compiled but interpreted, meaning that the process of translation into executable machine code happens immediately, merging writing and execution of software.

5. The archetypical computer, the Turing machine, demonstrates this dichotomy of modular and linear. A piece of tape, infinitely long, contains sequenced symbols, one of which is at the read-head at any given moment. The symbols on the tape constitute a module, with a beginning and an end. The read-head designates the linear, a fixed state about to enter a next state. In parallel with this linearity/modularity of the tape, the machine also has a prepared menu of actions, with the current state of the machine and the current symbol at the read-head determining which next action to take and which next state to assume. (We might call this menu the operating system of the machine.) This menu of actions (one action for each combination of state and symbol) makes another module of the Turing machine. Correspondingly, there is the particular state that the machine is in at any given moment, which is always on the way to the next state (linearity). Modular becomes linear when the machine runs.

6. My brief treatment here of the history of software is no doubt too linear. Like most histories, software's is full of stops and starts, anticipations and hesitations. While the history traced here is accurate in broad outlines, it elides the complications inherent to any history, and borrows its sense of progress as much from genealogy as from a legitimate chronology. Nevertheless, the dominant trend is discernable, and progresses, as I will outline below, toward the object.

7. The binary values are grouped into bytes and words, and these are represented in assembly code by letter combinations: AINC for increment the assembler, 10110010, for instance. By a simple substitution of letter codes for number codes, assembly language makes the computer program more readable and writable.

8. To say that scoping is enforced by the compiler means that the compiler will generate an error when the programmer attempts to compile code with a reference to a variable outside of the appropriate scope of that variable. The compiler notifies the programmer of the error and fails to generate a usable executable.

9. OOP was first developed in the 1960s but did not gain widespread use until the late 1980s. Ten years after that, it had become the standard programming paradigm, employed on most major programming projects and taught in university-level programming classes. (To be clear, OOP is a paradigm or method of programming, used in conjunction with certain programming languages that are designed for it. There are quite a few particular programming languages that realize the OOP paradigm, including Java, C++, C#, Object Pascal, Smalltalk, and more.)

10. Terminology varies among different programming languages. Procedures might be called functions, algorithms, subroutines, or methods. Data might be called members or elements. And categories of objects are often called classes. Also, not every OOP environment is based on classes, and there is considerable debate about the precise criteria essential to the definition of OOP.

11. Example: in the code for a typical object-oriented drawing program, a Shape category would include a datum, Shape.center, to store the central point or location of the shape. The Circle category, a child of Shape, would inherit Circle.center from Shape and would also add to it a Circle.radius datum, defining a circle. Polygon could be another child of Shape, augmenting the data in the Shape category to include not only a radius but also Polygon.num_sides and Polygon.orientation, specifying the number of sides in the polygon and the angle at which the polygon is rotated, respectively. These three categories (Shape, Circle, Polygon) are written in the source code at compile-time. At run-time, the user might use the “circle” tool or the “polygon” tool, which would result in the creation of some instances of Circle or Polygon objects, with particular centers, radii, numbers of sides, etc. Central to the operation of the program would be the instantiation at run-time of these various shapes, children of the Shape category, but while circles, polygons, rectangles, triangles, and more could all be instantiated, there would likely be no way to instantiate at run-time a pure Shape object. (What would such a thing be?) The Shape category functions as an organizational tool, containing data structures and procedures common to all shapes, thus saving the programmer from having to include these data and procedures in each of the child categories. A category like Shape, used organizationally but not intended for instantiation, is called a pure virtual class in C++.

12. There are significant, deliberate technical elisions in this explanation. Clear rules allow most references to this to be unambiguously resolved at compile-time. Most cases of polymorphic (ambiguous) reference can be resolved from syntax and do not require run-time calculation. But the situation in which this is ambiguous at compile-time is not only possible but quite frequent, and the example thus illustrates a legitimate facet of OOP. A further caveat: polymorphic ambiguity has little to do in principle with the this pointer, which is being used here as a provocative example.

13. Subjects tend to have desires of their own, so a computer-as-subject might be less compliant than we would want, or even altogether dangerous. While this is surely a serious concern, I argue elsewhere that the interface only inspires creativity when it resists the efforts of the user. Some sort of subjectivity in the machine is essential to the most creative employment of it.

14. Kittler's wonderful “There Is No Software” expresses alarm at this increasing abstraction, as he worries that our relationship to the computer hardware is too mediated, that we don’t (any longer) understand the consequences of our actions at the computer. This influential view must be reckoned with, though I believe that it romanticizes hardware as inherently knowable and treats software as mysterious or obscure. The present analysis agrees that increasing layers of abstraction may indeed wrest more control from the user and programmer but suggests that the creative openings compensate to some extent for these hazards.