Objects Have Failed

(Opening remarks by Richard P. Gabriel, November 6, 2002)

What can it mean for a programming paradigm to fail? A paradigm fails when the narrative it embodies fails to speak truth or when its proponents embrace it beyond reason. The failure to speak truth centers around the changing needs of software in the 21st century and around the so-called improvements on OO that have obliterated its original benefits. Obsessive embrace has spawned a search for purity that has become an ideological weapon, promoting an incremental advance as the ultimate solution to our software problems. The effect has been to brainwash people on the street. The statement "everything is an object" says that OO is universal, and the statement "objects model the real world" says that OO has a privileged position. These are very seductive invitations to a totalizing viewpoint. The result is to starve research and development on alternative paradigms.

Someday, the software we have already written will be a set of measure 0. We have lived through three ages of computing—the first was machine coding; the second was symbolic assemblers, interpreter routines, and early compilers; and the third was imperative, procedural, and functional programming, and compiler-based languages. Now we are in the fourth: object-oriented programming. These first four ages featured single-machine applications. Even though such systems will remain important, increasingly our systems will be made up of dozens, hundreds, thousands, or millions of disparate components, partial applications, services, sensors, and actuators on a variety of hardware, written by a variegated set of developers, and it won’t be incorrect to say that no one knows how it all works. In the old world, we focussed on efficiency, resource limitations, performance, monolithic programs, standalone systems, single author programs, and mathematical approaches. In the new world we will foreground robustness, flexibility, adaptation, distributed systems, multiple-author programs, and biological metaphors for computing.

Needless to say, object-orientation provides an important lens through which to understand and fashion systems in the new world, but it simply cannot be the only lens. In future systems, unreliability will be common, complexity will be out of sight, and anything like carefully crafted precision code will be unrealistic. It’s like a city: Bricks are important for building part of some buildings, but the complexity and complicated way a variety of building materials and components come together under the control of a multitude of actors with different cultures and goals, talents and proclivities means that the kind of thinking that goes into bricks will not work at the scale of the city. Bricks are just too limited, and the circumstances where they make sense are too constrained to serve as a model for building something as diverse and unpredictable as a city. And further, the city itself is not the end goal, because the city must also—in the best case—be a humane structure for human activity, which requires a second set of levels of complexity and concerns. Using this metaphor to talk about future computing systems, it’s fair to say that OO addresses concerns at the level of bricks.

The modernist tendency in computing is to engage in totalizing discourse in which one paradigm or one story is expected to supply all in every situation. Try as they might, OO’s promoters cannot provide a believable modernist grand narrative to the exclusion of all others. OO holds no privileged position. So instead of Java for example embracing all the components developed elsewhere, its proponents decided to develop their own versions so that all computing would be embraced within the Java narrative.

Objects, as envisioned by the designers of languages like Smalltalk and Actors—long before C++ and Java came around— were for modeling and building complex, dynamic worlds. Programming environments for languages like Smalltalk were written in those languages and were extensible by developers. Because the philosophy of dynamic change was part of the post-Simula OO worldview, languages and environments of that era were highly dynamic.

But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence.

And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair.

Beyond static types, precise interfaces, and mathematical reasoning, we need self-healing and self-organizing mechanisms, checking for and responding to failures, and managing systems whose overall complexity is beyond the ken of any single person.

One might think that such a postmodern move would have good consequences, but unlike Perl, the combination was not additive but subtractive—as if by undercutting what OO was, OO could be made more powerful. This may work as a literary or artistic device, but the idea in programming is not to teach but to build.

The apparent commercial success of objects and our love affair with business during the past decade have combined to stifle research and exploration of alternative language approaches and paradigms of computing. University and industrial research communities retreated from innovating in programming languages in order to harvest the easy pickings from the OO tree. The business frenzy at the end of the last century blinded researchers to diversity of ideas, and they were into going with what was hot, what was uncontroversial. If ever there was a time when Kuhn’s normal science dominated computing, it was during this period.

My own experience bears this out. Until 1995, when I went back to school to study poetry, my research career centered on the programming language, Lisp. When I returned in 1998, I found that my research area had been eliminated. I was forced to find new ways to earn a living within the ecology created by Java, which was busily recreating the computing world in its own image.

Smalltalk, Lisp, Haskell, ML, and other languages languish while C++, Java, and their near-clone C# are the only languages getting attention. Small languages like Tcl, Perl, and Python are gathering adherents, but are making no progress in language and system design at all.

Our arguments come in several flavors:

The object-oriented approach does not adequately address the computing requirements of the future.
Object-oriented languages have lost the simplicity—some would say purity—that made them special and which were the source of their expressive and development power.
Powerful concepts like encapsulation were supposed to save people from themselves while developing software, but encapsulation fails for global properties or when software evolution and wholesale changes are needed. Open Source handles this better. It’s likely that modularity—keeping things local so people can understand them—is what’s really important about encapsulation.
Objects promised reuse, and we have not seen much success.
Despite the early clear understanding of the nature of software development by OO pioneers, the current caretakers of the ideas have reverted to the incumbent philosophy of perfect planning, grand design, and omniscience inherited from Babbage’s theology.
The over-optimism spawned by objects in the late 1990s led businesses to expect miracles that might have been possible with objects unpolluted by static thinking , and when software developers could not deliver, the outrageous business plans of those businesses fell apart, and the result was our current recession.
Objects require programming by creating communicating entities, which means that programming is accomplished by building structures rather than by linguistic expression and description through form, and this often leads to a mismatch of language to problem domain.
Object design is like creating a story in which objects talk and interact with each other, leading people to expect that learning object-oriented programming is easy, when in fact it is as hard as ever. Again, business was misled.
People enthused by objects hogged the road, would not get out of the way, would not allow alternatives to be explored—not through malice but through exuberance—and now resources that could be used to move ahead are drying up. But sometimes this exuberance was out-and-out lying to push others out of the way.

But in the end, we don’t advocate changing the way we work on and with objects and object-oriented languages. Instead, we argue for diversity, for work on new paradigms, for letting a thousand flowers bloom. Self-healing, self-repair, massive and complex systems, self-organization, adaptation, flexibility, piecemeal growth, statistical behavior, evolution, emergence, and maybe dozens of other ideas and approaches we haven’t thought of—including new physical manifestations of non-physical action—should be allowed and encouraged to move ahead.

This is a time for paradigm definition and shifting. It won’t always look like science, won’t always even appear to be rational; papers and talks explaining and advocating new ideas might sound like propaganda or fiction or even poetry; narrative will play a larger role than theorems and hard results. This will not be normal science.

In the face of all this, it’s fair to say that objects have failed.