A Flock of COOTS

In the "blue" UNIX issue of BSTJ (1978), Ritchie, Johnson, Lesk, and Kernighan ended their article on C with ,"We leave it to the reader to speculate whether it [the successor to C] should be called D or P." It was to be neither. It was C++.

A decade ago, Dave Yost - who didn't know better at the time - suggested a C++ workshop to the USENIX board, of which he was then a member. The workshop was held in Santa Fe, NM, November 9-10, 1987, though by then Dave had been converted to Eiffel. Bjarne Stroustrup was the keynote speaker. Interest was so great that in 1988, USENIX held a C++ Conference in Denver, October 17-21, with Bill Joy as the keynoter. Eighteen months later, there was a C++ Conference in San Francisco (April 9-11), where Adele Goldberg delivered the keynote. Barely a year thereafter, the third Conference was held in Washington, DC, with David DeWitt as speaker (April 22-25, 1991). Portland, OR, hosted the next C++ Conference (August 10-13, 1992), with Kristen Nygaard as keynote. And April 11-14, 1994, saw the last C++ Conference in Cambridge, MA; with Peter Deutsch as keynote speaker. Though these were C++ conferences, not general OO conferences, the keynote speakers were deliberately chosen from outside the C++ culture in the hope of adding new ideas. Goldberg's was interesting and Nygaard's keynote was head-and-shoulders above the rest. (Nygaard and Dahl created Simula, beginning in spring 1961.)

With the exception of Adele Goldberg's address in 1990, there were no talks concerning things other than C++: no Simula, no Smalltalk, no Eiffel. I don't mention CLOS or Ada3, nor Modula3, as they didn't exist early on. But with the metamorphosis of the C++ Conference into the Conference on Object-Oriented Technologies (Monterey, CA, June 26-29, 1995), there was a flurry of papers on distributed objects, on Phantom, on Lingua Franca, etc., introduced by Mike Powell as keynote. Last year in Toronto (June 17-21), COOTS varied its name (O-O Technologies and Systems), the keynote speaker was Dave Thomas, and the papers covered a wide range of topics: CORBA, tools, frameworks, components, and Java, as well as C++. Five of those papers appeared in the final issue of Computing Systems.

The object fanciers were back in Portland in June (16-20); and Bjarne Stroustrup was again the keynote. Shakespeare tells us that "The past is prolog." And all the above is prefatory to my remarks on Stroustrup's talk, "Programming Languages - Why should we care?".

Stroustrup began by noting that this was a topic suitable for days of discussion, not an hour; and then forged ahead. He asked (rhetorically) what programming languages were for and responded they that supplied a selection of questions and their answers, criteria of various sorts, and a design space. This was really nice, as it would be true for natural languages, too; the many words for snow or sandstorm in some, the varying syntactic and morphological forms, the inability to say some things in other languages (try to translate Gem¸tlich into a single word in English or Turkish).

"I love writing code," said Stroustrup, "but I hate fixing bugs. . . . I can write the same program in C++ or C or Ada, but no one will see the structure if it isn't explicit. . . . Explicitness and the automation of frequent tasks" are the key.

We can ask the question, "Why do we need programmers and programming?" In a CASE world, in Ada, you do different things. But where do those frameworks come from? Things not in the framework must be constructed - if we need to create a new service, for example. "Proprietary languages make things difficult when you hit the edge," Stroustrup said. "It's either a reasonably clean mathematical model, or it's messy. We can do without traditional programming in realms that have been studied to death and preferably have a clean mathematical model. . . . A language doesn't solve your problem; a good language can help you express the solution to your problem. . . . All languages have serious limitations - I probably know most of the flaws in C++, but I respect the limitations and know how to prevent them from getting in my way."

Stroustrup went on with the question of languages. "There is no one language solution," he said. "It doesn't matter which language we use. What matters is when a language just fulfills the task at hand. Is there room for a general purpose language? Yes. Is there a possible all-purpose language? No. The idea of a single language is dangerous; one size doesn't fit all problems. People with ambitious goals do unusual things."

Stroustrup confessed himself to be an adherent of the Whorfian hypothesis (that there is a determinative relationship between language and culture), though the strongest form is nonsense for natural languages, it appears to have relevance to programming where languages are designed to favor some forms of thought and discourage others. We can't just have special languages for each area or subarea, because the interesting things happen at the intersections of fields. "Languages grow to add features in a fashion." Stroustrup went on to say that "We cannot just pander to application domain experts."

"C++ doesn't provide you with anything but tools for building libraries and applications," he said. "Can morality be enforced? No. Any general language will allow bad code. . . I don't think a programming language should be a design language; a complete design language cannot be a general purpose programming language. There is no substitute for

• Intelligence
• Experience
• Taste
• Hard work."

Stroustrup indulged in a bit of C++ history, because "C++ is what I know best." He said it was an extension of C with "Simula's ability to organize. Declarative syntax was an experiment that failed.'" C with classes was a "medium success," he noted, but there was no support infrastructure. "You need 5,000 programmers to support an infrastructure,'' he said, and the alternative was to get it out, get more users, improve it, and end up with more support for the growing audience. The evolution of C++ was thus driven by real problems, with no quest for perfection. The result of that is that C++ is still useful: every feature must have an obvious application; there is a clear transition path; it is a language, not a system; it has comprehensive support without forcing programmers into a mold.

Stroustrup said that one of the important concepts was that of design support. Unlike ML, where everything is deduced, C++ has "explicit support," which is superior to deduction. C++ is better than C in that it supports data abstraction, object-oriented programming, and generic programming [templates]. As C++ is Turing-complete, it can be used to program anything. But that's the wrong question. The right question is "What can't be done efficiently or only with difficulty?" Stroustrup said that the weak spots were "concurrency, distributed computing consistency, and persistency." But he noted that "the big thing is how you build your libraries."

Stroustrup pointed out the utility of name spaces, which enable the programmer to "represent things in source, representing them with a 'name'," as well as exception handling, which yields a "uniform mechanism for signalling errors.'"

Heady wine for 9 am.

Advanced Topics Workshop

Having begun with Stroustrup, we ended with a workshop: under 40 of us. The organizer this year was Rajendra Raj. The agenda included 11 submissions representing a variety of points of view. With participants from Portugal across North America to New Zealand, the range can be imagined.

Raj had mentioned "components" in his brief opening remarks. "Components" was one of the main topics of the Advanced Topics Workshop. With the word in several titles, Doug Lea and David Zager actually started a discussion of just what were objects and what were components. I was fascinated. Among the statements were:

• Components are C++ objects working together, with a single interface to the collection
• Components span areas, while objects are unidimensional
• Things like Java Beans are components.
• Several folks noted that it would be nice to have reliable APIs.

Reliability was a strong topic. Everyone concurred on the merits of reliable distributed objects, drawing up a list of components of reliability:

• Availability
• Performance
• Response time
• Trust
• Security
• Integration support

Beginning its second decade, COOTS (a.k.a. C++) returns to Santa Fe next year. I'm looking forward to it. Perhaps some problems will have been solved as others loom ahead. The program chair will be Joe Sventek, of HP Labs, one of the original members of the Software Tools User Group (1978). From VOS to C++ and Java! That's a true intellectual journey.

Finally, it's important for me to acknowledge that the Advanced Topics Workshop, with attendance under 40, is both a valuable experience for participants, but expensive. I'd like to formally thank the Hewlett-Packard Company for its sponsorship. (And the free lunch was pretty good.)