As I walked through New Orleans's colorful French Quarter one hot night in early October, a man caught my sleeve and offered to bet me five dollars that he could guess where I got my shoes. I declined his tempting offer, assuming that the answer was, in a shoe store. I was in town for the Fourth Annual Conference on object-oriented systems, languages, and applications (OOPSLA '89), and the next morning as I sat listening to a panel discussion, it struck me that this was an object-oriented gag, deliberately confusing class with instance. Maybe OOPS is taking over the world.
It was easy to believe that there was an object-oriented revolution underway that day at the show. There was a lot of enthusiasm, and there were a lot of people. Although claims of 2000 attendees at last year's OOPSLA may have been exaggerated, this year there probably were about that many. The preregistration and on-site registration attendee lists give 1626 names, by my count. In any case, the figures don't reflect the mad rush when the exhibit doors opened Tuesday morning. Although they gave different reasons, everyone I asked said that this OOPSLA was the best they'd been to.
Some attendees had a greater presence than most. Apple announced its C++ and talked around the edges of Apple Script, its planned user programming language. Borland announced Turbo Pascal 5.5 with object-oriented support. But there was more interest in what might be coming in the next few months from Borland and from Microsoft, which was not present as an exhibitor, although a number of Microsoft employees were there. The biggest presence at OOPSLA '89, though, was definitely C++, already the most widely-used object-oriented language and spreading like -- well, you can supply your own simile. Some people think C++ is a disease that we will all soon be required to contract.
All the expected exhibitors were there: Digitalk, The Whitewater Group, and Interactive Software Engineering in the booth right in front of the entrance. But there were few announcements of importance; this was an ACM conference, not Comdex, and the real action was in the presentations.
The tutorials began the conference, and to a certain extent, they reflect the topics of greatest programmer interest or areas of greatest difficulty in OOP today, because they cover the topics that teachers of OOP are finding a demand for. Most of the tutorials were not specially created for the show but are classes that people in the field have been putting on over the past year.
Jon Pugh of Carleton University set up the tutorials, which included introductions to OOP concepts, MacApp, and C++, plus object-oriented issues in databases and concurrency. There were also tutorials evaluating OOP environments, including NextStep, C++, Smalltalk, MacApp, and a portable C++ class library for Unix called "ET++," along with more advanced tutorials on object-oriented analysis and design, prototyping, and managing object-oriented software projects. ET++ is likely to get a lot of attention, because there's not much out there in the way of libraries for C++.
After two days of tutorials, the conference proper began. The emphasis in the conference program shifted this year away from some peripheral issues such as general software engineering, user interface design, and databases, and toward more depth of coverage in theory, language design and implementation, and concurrency. Conference Chair Kent Beck explained that the peripheral areas were welcomed in the past because they would not have got a proper hearing in any other venue until recently. Now, though, object-oriented work is invading the general computer magazines and journals and other conferences, and OOPSLA could get more focused.
The overall impression I got from the attendees, the exhibits, the tutorials, and the conference program, was of a fringe thread in the process of being pulled up into the general fabric of software research and development.
Except, of course, for the fact that there still does not seem to be a universally accepted definition of object-oriented programming.
If you can believe Johnny Carson, some 20 percent of the people in this country examine their belly buttons daily. A disproportionate number of these navel observers were at the Hyatt Regency in New Orleans the first week in October, asking themselves and each other what object-oriented programming is. To be fair, I should add that just as many people were answering the question as asking it; I just wish I could say that they were giving the same answer.
The answer involves some subset of these features, apparently: These data/ code hybrids called objects, object classes of which particular objects are instances, an inheritance mechanism defined on these classes, and the ability to define new object classes. At least one language has been called object-oriented despite the lack of each of these features, although each has been put forth as necessary by one authority or another, and all at OOPSLA '89.
The keynote speech by Peter Wegner of Brown University was a proper question raiser and territory mapper. Wegner wrote the first book on Ada and got interested in object-oriented programming early on because of his perception of Ada's deficiencies as a language for software engineering. In Wegner's view, the goals of object-oriented programming are: Creating a technology of off-the-shelf software components, developing distributed national and international software libraries, and growing to a capital-intensive software technology in which one can buy rather than build. He also sees, as a present goal, the extending of OOP to encompass what he calls OOP in the large: Object-oriented systems supporting concurrency and persistent objects for multiple computers and multiple users, and distributed data and cooperative computing.
Not all the presentations followed Wegner's map.
One session described SELF, a dynamically-typed object-oriented language. The authors, Craig Chambers, David Ungar, and Elgin Lee, all of Stanford, presented an object-oriented approach that substitutes prototypes for classes. Although SELF has objects and inheritance, by Wegner's criteria it is not object-oriented, because it has no classes. Objects are cloned from other (prototype) objects, from which they inherit behavior directly. In another session, Ungar predicted that prototype-based languages will ultimately replace class-based ones.
Of more immediate interest than the implementation peculiarities of the SELF language, though, is the fact that SELF runs twice as fast as the fastest Smalltalk implementation, even though SELF is inherently less efficient than Smalltalk. The authors have optimized SELF with techniques applicable (but not yet applied) to any other object-oriented language, and have not had to hardwire any user-level operations into the compiler, as some researchers have done with Smalltalk implementations. They bluntly say "researchers seeking to improve performance should improve their compilers instead of compromising their languages."
That could be the answer to one of the other nagging issues in object-oriented programming: Can an OOP system provide the strong typing needed for software engineering and at the same time remain a good system for rapid prototyping? Those of a software engineering bent and those who like OOPS for rapid prototyping both like inheritance, but seem to use it for different purposes. The differences revolve around type checking and the relationship between types and classes. Panelists in one session argued that types and classes are really orthogonal and should not be confused; and that programming environments could be, but are not, constructed to support both production and exploratory programming. But one dissenter, David Stempel of the University of Massachusetts, said that the only way that one environment can support both styles of programming is by really being two environments, with a switch to turn off prototyping features when in production mode.
Several talks dealt with the teaching of OOP concepts. The simplest technique presented was in some ways the most intriguing. Kent Beck of Apple and Ward Cunningham of Wyatt Software Services presented an index-card-based approach they have been using to teach OOP. The approach involves representing objects with 3 x 5 index cards, and placing the cards in appropriate physical relationship to one another. A card contains three kinds of information about the object: Its class name, its responsibilities (problems it is to solve), and its collaborators (what other classes it messages or is messaged by), presumably written in pencil for easy modification. This simple technique apparently underscores the objectness of the objects, and the authors report students picking the cards up and waving them around to demonstrate their interaction.
There's not even agreement that software engineering is the goal of OOP, although many people not only believe it to be the goal but even speak as though there were such agreement.
The early afternoon of the first day of the program was given over to software engineering papers and a panel on the more-or-less SE-oriented topic of the role of transactions in object-oriented systems. A couple of other panel discussions directly addressed software engineering concerns as well, including a discussion moderated by Brad Cox on the software industrial revolution. Cox was of the opinion that the revolution will need more than interchangeable parts -- it'll also need gauges or templates to ensure that the parts fit. He stressed the importance of developing the gauges apart from the parts they test - possibly even employing a different technology to develop them.
There was one field report from pioneers trying to build a full software development environment using object-oriented technology. William Harrison, John Shilling, and Peter Sweeney described their system, which runs on a PS/2 under OS/2, an RT/PC under AIX, and even an AT under MS-DOS in 640K RAM. (Two of them work for IBM.) The system has a persistent object store -- the object-oriented version of a file system. With some 200,000 objects in their store, the authors have some experience with the use of objects, and it is suggestive that they found that organizing objects by type hierarchy did not work well, because their actual use of objects did not reflect a type hierarchy. They found some serious hurdles, too, and concluded that the object-oriented paradigm needs some extensions if it is to be used for things such as version control, and that the paradigm currently does not provide the necessary support for modifying and extending the paradigm itself.
Lt. Col. John Morrison of the National Test Bed spoke briefly of one of the more ambitious software projects to date: The Strategic Defense Initiative. Whether one thinks SDI is a brilliant and achievable project or a fast one put over on a gullible chief executive, SDI research should be a remarkable testbed for software engineering and reusable components. One of the elements is intended to be a large national library of reusable software components.
Others discussed how they were using object-oriented technology for real applications in commercial software development, CAE/CAD, and scientific computing.
Aldus personnel discussed how they are using object-oriented techniques to manage software development in expanding teams of developers in the face of competitive pressure to deliver. The Aldus VAMP system has helped them isolate the developer from differences in Macintosh and Windows event-dispatching, for example.
There were several presentations on business applications. Two that seemed significant were an implementation of security in an object-oriented system at MCC, and a language developed at GE Corporate R&D and Calma. The MCC system implemented security levels from Unclassified through Confidential and Secret to Top Secret, more than the average business requires, one would think, but it was classified as a business presentation. The system from Calma and GE, called DSM, is designed for commercial CAE/CAD applications. DSM supports most of the features expected in an object-oriented language and is reported to be nearly as efficient as writing straight C code. The only explanation offered for this remarkable performance was that DSM trades memory for speed.
Papers on scientific computing came from three distinct object-oriented backgrounds: CLOS (the Common Lisp Object System), Smalltalk, and C++. Besides talks on systems for function minimization, automatic differentiation, and linear algebra, there was an interesting discussion of scientific prototyping. I guess what I found most interesting about it was the realization that the ability to construct 3-D computer models of objects and processes and to manipulate the models has become an essential tool of scientific research. Sandra Walther and Richard Peskin presented a Smalltalk-based scientific prototyping environment that uses C primitives for efficiency.
Is OOP seeing real use in embedded systems development? Design? Implementation? And does it have a future there? The one case study of embedded system development presented at the conference suggests what one might expect: OOP was a good tool for managing the development process and coming up with the basic design in a short time, but the actual implementation required substantial recoding in C and assembler.
Any description of the state-of-the-art in any developing field always sounds wrong to some part of the audience. What looks close to SOA to one person may be SF to another. To traditional DP professionals it may be a non-issue: Bill Joy said he did not consider traditional DP professionals a market for OOP because they would not understand it. Later, being fair, he added that he'd say the same about most C programmers.
Bill Joy said that, not me. My only point is that the state-of-the-art has thickness; it's not so much a time slice as a time loaf. At OOPSLA '89 there were SOA talks on theory, and SOA talks at the implementation level.
A couple of the implementation issues on the edge are efficient garbage collection and how to implement persistent objects and virtual memory for objects. One of the concepts being usefully employed in garbage collection is the notion of a generation: Several systems separate objects by age, focusing garbage collection on the youngest generation, where turnover is likely to be most rapid.
One of the more interesting theoretical papers showed that inheritance, rather than being merely a feature of object-oriented programming, is a general method that can be applied to any form of recursive definition.
Some presentations were state-of-the-art in any sense, focusing on concepts on the edge, such concurrency, agents, and reflection.
Object-oriented programming decomposes problems in ways nicely suited to communicating processes in a parallel architecture. The conference demonstrated that there are real implementations of OOP systems that implement fine-grained parallelism, although they probably won't run on your machine yet.
Several talks dealt with agents that may turn out to be important for making sharable, reusable software components work in practice in widely distributed systems. Agents are independently executing entities sensitive to particular stimuli. Such entities could be trained to search libraries for the software components needed. In "Swaine's Flames" I speculate about the economic consequences of such a system, but the need for some method of automating the search for software components seems clear. If one of the goals of object-oriented programming is reusability, and if objects are going to multiply as fast as some of the presentations at the conference suggest, automating the process of connecting the component with the person who needs it will be essential.
Reflection is the ability of a system to represent and reason about itself. It turns out to be relatively easy to implement some form of reflection in Smalltalk and some other OOP languages. The benefits discussed at the conference include modifying the behavior of the system, monitoring entities of the system, and self reorganization (learning). Formerly viewed as an academic topic, reflection is beginning to be considered for practical implementations. One presentation discussed a way of implementing many of the benefits of full reflection with no cost in efficiency.
Maybe reflective programs could debug themselves. That would be handy.
During one of the panel discussions, Bjarne Stroustrup, humble developer of an arrogant language, told the audience that anyone claiming that object-oriented programming will bring about bug-free software was probably spending his evenings in the French Quarter guessing where people got their shoes. I didn't notice if Lt. Col. Morrison laughed.
Copyright © 1989, Dr. Dobb's JournalTalking About a Revolution
Views from the Navel Observatory
Getting Software Engineering on the Track
Real Applications
The State Space of the Art