Dr. Carlo Pescio Interview with Bertrand Meyer

Published in Software Development, Vol. 5 No. 9, September 1997, as "The View from the Eiffel Tower".

Bertrand Meyer, originator of the development method known as Design by Contract, is one of the most original thinkers in the field of object-oriented technology. His method brings some of the better aspects of formal methods and the industry's best practices together. He also designed Eiffel, an object-oriented programming language that is tightly integrated with the notion of Design by Contract. Along with these achievements, he has authored numerous articles and books, and is the chair of the TOOLS (Technology of Object-Oriented Languages and Systems) conference series.
I've had the pleasure to talk with him about some hot topics in software development. They include the adoption of pure or hybrid languages, the role of CASE tools, and the choice of an analysis and design methodology.

CP: Eiffel is a statically typed, pure object-oriented language. Most people understand the advantages (from a software engineering perspective) of statically typed languages compared to dynamically typed languages like Smalltalk. However, it seems difficult to find compelling, pragmatic, real-world examples that show why a pure object-oriented language is better than a hybrid like C++ (which, on the other hand, presents a smoother transition path). I've seen a lot of hand-waving about the benefits of pure languages, but little real-world evidence. Can you offer a good, practical example of how Eiffel purity is better than hybrids such as C++?

BM: First, I should mention that Eiffel only partly competes with languages such as C++ and Java. It should actually be viewed as a system construction mechanism that you can use to bring software components together. Some of these components will be written in Eiffel; but it is also important to reuse components written in C, C++, Java, FORTRAN, and so forth. For that reason, Interactive Software Engineering (ISE) has devoted considerable efforts to developing a full-fledged interface to these languages. You can call C, C++, and so forth from Eiffel, and vice-versa. We even have a new tool called Legacy++ that will take a C++ class and produce an Eiffel class that completely encapsulates it. Legacy++ is documented on our web page at http://www.eiffel.com. Using Legacy++, you can integrate existing C++ code into an Eiffel application as if it were originally created in Eiffel.

More generally, what matters to me is not some abstract notion of purity (a term I don't use), but an emphasis on quality. By sacrificing to some degree of compatibility such as C, one may fail to get the necessary quality. This is not a matter of aristocratic idealism, but the consequence of technical deficiencies.

As a result, many people have commented that Eiffel is easier to learn than hybrid approaches. In fact, it offers a smoother transition path because it's consistent. With a hybrid, you are constantly faced with concepts from different backgrounds-some object-oriented, some C. These backgrounds are often incompatible, which makes learning more difficult. For example, C++ and Java keep the syntax of C. David Clark, from the University of Canberra, has taught students with both Eiffel and Java. Documenting his experience, he writes [in an unpublished technical report], "My experience has been that students do not find Java easy to learn. Time and again the language gets in the way of what I want to teach....The first thing they see is public static void main (String [ ] args) throws IOException.

"There are about six different concepts in that one line which students are not yet ready to learn....The only way to read a number from the keyboard is to read a string and parse it. Again, this is something that crops up in the first lecture. Java treats the primitive data types (int, char, boolean, float, long, and so forth) differently from other objects....The lack of generics means that you are forever casting if you want to use a collection of elements such as Stack or Hashtable. [These things] are hurdles for beginning students, and distract them from the main learning outcomes of the course."

This is just as true for professional developers. One of the reasons for the success of Eiffel in large industrial projects is that people with all kinds of backgrounds (programmers, bankers, traders, mathematicians, engineers, and so on) can learn it quickly and effectively-without having to master tricky and error-prone constructs coming from C. A list of concrete unpleasantries would include:

In C++ and Java, as noted by David Clark, the basic types (int and the like) don't fit within the object-oriented type system. This makes a whole set of object-oriented patterns impossible to program.

The absence of genericity in Java complicates programming and leads to serious inefficiencies (such as the need to decode types at run time), and insecurities, since it is impossible to do full static type checking. In plain terms: run-time crashes!

A language that retains the arbitrary casts of C impedes or prevents garbage collection. The result is manual memory management, meaning longer development, boring work for the programmers, and the risk of bug-ridden software because of pointers detecting memory areas wrongly reclaimed.

The absence of multiple inheritance in Java precludes using many of the most useful patterns of object-oriented development, which combine several abstractions into a new one.

This list goes on. It's not a matter of purity per se; it's a matter of building software quickly and effectively-in other words, of making money if it's done well-and losing money otherwise.

CP: Eiffel has been around for approximately 10 years. I think its popularity is growing, thanks in part to better tools and support. Still, it doesn't seem to be about to "go nova." What do you think Eiffel is missing that will help it gain the necessary momentum? What is the secret ingredient that will make it explode like Java?

BM: In terms of numbers of licenses, ISE Eiffel's reach is in the tens of thousands, which is fewer than other approaches. But in terms of actual applications, some of the most successful object-oriented projects (I should emphasize successful, because the O-O field has not been immune to disasters) have been produced using Eiffel.

For example, in banking and financial applications, ambitious projects that can make or lose millions of dollars for their companies tend to turn to Eiffel. A well-publicized effort is the CALFP Bank project, where the entire bank's operation relies on 700,000 lines of ISE Eiffel. This was developed on time and within budget by a group of people, two thirds of whom weren't software professionals (they were traders, economists, and bankers). They immediately took to Eiffel because of its clarity, simplicity, and effectiveness, and because it helped them program their pricing models and financial products directly.

It's hard to imagine this working with other languages -- traders writing code code full of { and }, &, and *, and getting the result right. No amount of marketing material is going to help you when your software does not work.

CP: What's your opinion of the Java boom?

BM:What is exciting about Java is the virtual machine and its promise of instant portability. This is, however, is achieved at a high cost in expressiveness and in efficiency.

CP: In a few cases, I've seen Eiffel scare people. On closer observation, I noticed it was not the language itself, but the notion of Design by Contract. Programmers without a formal computer science or software engineering background simply weren't used to thinking about programming that way. They found it very difficult to change their mentality, and were afraid of wasting time with niceties instead of getting the job done. Also, I've seen a few engineers who were very skeptical about the usefulness of assertions outside well-known domains (like the evergreen stack). In some sense, Design by Contract shares most of the difficulties, rewards, and myths of formal methods (which had no more luck outside academia). Is it just a matter of education (also at the management level), or are there real impediments to the widespread use of Design by Contract?

BM: That's quite interesting. I have seen many people apply Design by Contract, but haven't seen anyone who was scared by the actual techniques, which are simple and accessible to anyone with a secondary education.

Actually, the idea of Design by Contract is precisely to avoid the exaggerations of formal methods and to yield something concrete that can be used to benefit all developments, large and small, at little cost. The consequences are just fantastic: with hardly any extra effort, you get software that works the first time around. It is incredible how quickly you find potential bugs before they have had the time to hit you. It's something that anyone can use; the techniques are simple and easy to apply.

The real question is whether or not you can afford not to apply it. The crash of the European Space Agency's Ariane 5 launcher in June 1996-$500 million up in smoke in a few seconds-was entirely due to the reuse of a routine without the proper assertions (the proper contract). With Design by Contract, the bug would have been caught right away during quality assurance, or probably would not have occurred at all.

It is unbelievable that some people think they can have large-scale reuse without contracts-in Java, C++, Ada (the language used for Ariane), and so forth. Reusing a component without a proper specification of what it is supposed to do is sheer folly. As the Ariane example shows, it is better not to reuse in such a case.

As several people have written (including Tom deMarco, one of the most respected names in software engineering, in the February issue of IEEE Computer), only Eiffel-like assertions and the built-in contract mechanism have the basis for establishing a successful industry of reusable software components.

CP: What is your position about object-oriented analysis and design CASE tools? I've seen many companies where CASE tools are mostly used to make fancy pictures, and very few of those companies were able to use the tools in the full life cycle. In many senses, a notation such as the Business Object Notation [BON] makes it easier to do round-trip engineering. However, the Business Object Notation seems somewhat low-level when compared, for example, with modeling languages and notations like the Unified Modeling Language [UML]. Is it really better to use a notation that is closer to a programming language when doing object-oriented analysis and design?

BM: I agree with your assessment of how CASE tools are used in many companies. However, your comment about the Business Object Notation is surprising. It is certainly higher-level than the Unified Modeling Language, especially through its support of contracts. It is also much simpler.

CP: I guess that in some cases "higher-level" is in the eye of the beholder. Quite a few people would say that the Business Object Notation sacrifices associations, multiplicities, state diagrams, and so on in favor of reversibility. Some go further and say that this makes it closer to the programming language, so it's lower-level than, say, the Unified Modeling Language.

BM: The Business Object Notation does a very good job of identifying the set of basic concepts on top of which everything else can be built. The Unified Modeling Language is different. Its numerous basic concepts mix the important and the auxiliary, the difficult and the trivial. I think this is the result of its design process which, for fear of offending someone, took a little bit of everyone's buzzwords, a little of the object modeling technique, a few use cases here and there, Booch ideas (of course), genuflections to patterns, and so on. The result is too complex and not consistent enough for my taste. Compare this to the Business Object Notation, which is small, powerful, and simple.

The idea of an analysis method is to help analysts and developers think. If they have to start reading hundreds of pages of documents (such as the ones describing the Unified Modeling Language), they will never get to the real job. In contrast, the set of Business Object Notation diagram types fits on one page. I know, I reproduced them in the chapter on analysis in Object-Oriented Software Construction: Second Edition [Prentice Hall, 1997]. The method is there to help you, not to add extra obstacles to your effort. The basic concepts-seamlessness, contracting, reversibility, proper use of hierarchy, client-supplier relations, and life cycle activities-come from sound engineering principles; they can be mastered quickly and applied to the only task that matters: understanding the problem and building a quality solution fast.

It is not right, by the way, to characterize programming and programming languages as low-level. This may be true if you are using Basic, C++, or Java; but you can use a good programming notation for the highest level of activities. What could be more high-level than the Eiffel notions of deferred class and class invariant?

Looking at a high-level analysis document expressed in Eiffel, you can understand what it's about in a few minutes, not even realizing that you are learning a new notation, and start discussing the real problem-domain issues: What is the maximum heat in the furnace? Can there be several commercial breaks in a row during a television program? Do all lines in a paragraph have to be equally spaced? What is the maximum horizontal bias for the rocket? That's the kind of thinking we must express in an analysis-independent of any implementation concern. The Unified Modeling Language won't let you express them; Eiffel or the Business Object Notation will. Which one is of the highest level?

CP: You mentioned your book Object-Oriented Software Construction. What's new in this second edition for people who have read the first edition? Why should people who didn't read the first edition get a copy of the second?

BM: The second edition is thoroughly different and, I hope, far better. It is much more complete, with chapters on concurrency, persistence, many topics of methodology (such as finding classes and objects, using inheritance well, handling errors, teaching object technology, the software process, object-oriented analysis, and so on), typing, many design patterns, exception handling, multiple inheritance, and many others.

Even the sections adapted from the first edition have been thoroughly improved. The book comes with a CD-ROM that contains the entire hyperlinked text in Adobe Acrobat and a whole Eiffel environment so people can use it with their laptops. I certainly hope it will serve as a reference on object technology for a long time to come.

CP: Concurrent and distributed processing is going to be more and more important. I'm familiar with your Simple Concurrent Object-Oriented Programming (SCOOP) model, which I think is very elegant in its minimalism. However, isn't this minimalism going to alienate the hard-core programmers who want to feel in control? For example, synchronization based on precondition is very elegant, but what about time-out, so necessary in real-world programming? Also, is a run-time mechanism, such as the Concurrency Configuration File good enough to attract people working on massively parallel architectures, or is it mostly oriented toward a relatively coarse, distributed architecture?

BM: I think there is no contradiction between having a simple, uniform basic mechanism and providing extra facilities for people with special needs. Time-out is now part of the SCOOP framework; in fact, one of the detailed examples in the Object-Oriented Software Construction, Second Edition chapter on concurrency, a watchdog mechanism, uses time-outs extensively.

The Concurrency Configuration File is a basic way to link the SCOOP model with physical concurrency architectures, but others are possible, especially for fine-grain architectures. The model is quite open in this respect.

CP: To conclude, you are one of the few researchers who embrace a successful entrepreneurial and management career, and still do excellent research work. How do you manage to live in both worlds? Do you constantly watch out for the marketability of your research, or do you mostly try to make advanced technology practical, or is it something else?

BM: Thanks for your assessment. It is true that I enjoy both the academic world and the business world. There is no need for a split personality; both aspects are complementary.

Even from an academic perspective, the real test of success in software engineering is, in my opinion, whether someone, somewhere, likes your ideas well enough to apply them to his or her software development when the company's success and his or her own career depend on it. Without that validation, you don't know whether your ideas are any good at all. It's just too easy to propose all kinds of concepts that look great on paper. The only thing that matters in the end is whether they will lead to successful software development under the normal constraints of industry development: not enough money, not enough time, unpleasant competitors, impatient customers. Then you'll find out whether the ideas are any good.

That's why I devote essentially all of my time, right now, to working with ISE's customers, or on behalf of them. I see my task as making sure that our customers succeed with their projects. The rest-academic recognition, scientific progress, and so forth-follows when it can. The main goal is to help customers be successful with their own goals. The business benefits drive the rest. One of the pleasures of working in such an exciting field is that you often find out what's good for business is also good for science.

Reader's Map

Several visitors who have read this article have also read:

Biography
Carlo Pescio has a doctoral degree in Computer Science and is a consultant and mentor for various European companies and corporations, including the Directorate of the European Commission. He specializes in object oriented technologies and is a member of IEEE Computer Society, the ACM, and the New York Academy of Sciences. He lives in Savona, Italy and can be contacted at pescio@eptacom.net.