In this candid interview, Bertrand Meyer talks about Eiffel, object technology, the future of programming, and sleeping through the opera. Other articles by Bertrand Meyer.

Bertrand Meyer is the author of Object-Oriented Software Construction, 2nd edition (Prentice Hall PTR, 2000, ISBN 0136291554).

	Advertise With Us

Question: Can you give us some background on how you got started in software development?

Answer: My first introduction was a Fortran course, which I didn't really understand. I just couldn't figure out what the instructor was talking about. But then, during an internship in industry, where I didn't have much else to do, I got my hands on an Olivetti minicomputer—a personal computer, really—with a clearly written manual for its Fortran-like language, and I caught on right away. Back at school, I got interested in speech recognition and for an advanced degree did my first substantial programming, writing a program that separated phonemes in continuous speech. Soon after that, I came across an Algol 60 manual, and it was a revelation—the conciseness, the elegance, the logic. This is when I understood that programming wasn't just a means to achieve other goals, but a scientific topic of its own. It was, I felt, following the same principles of simplicity, style, and beauty, the embodiment of the great scientific tradition that we'd been taught, from Monge and Cauchy and Lagrange and Poisson and Laplace and Fourier and Ampère down to our own teachers such as Schwartz, and now I could find that same spirit again. This became even more attractive when I went to Stanford and took classes from people like Knuth, McCarthy, Floyd, found out about Lisp, about SAIL, about Wirth's Algol W, and started reading the programming methodologists, in particular Dijkstra and Hoare. I also came across Simula, and the same minute knew object-oriented programming was the only way that made any sense. (I thought everyone else knew this too.) Everything was falling into place.

Going to industry, I was in for a bit of a shock, since the techniques used were so different from what I had learned. But this was also a great opportunity. In the company I became, among other things, the resident methodologist, and in the process of building software myself and teaching software principles to my colleagues I quickly realized that competence and understanding were not all on one side. Industry also knew many things that academics didn't. Spending most of my career in industry has been good. I've always kept ties to university research and teaching, but having to solve practical problems—including, when I started my own company, having to find effective solutions on time as a very condition of existence—has kept me focused.

I have always felt a special thrill writing software. It's this incredible power of building a machine by just describing it. The description is the machine. If you can just specify what you want—and that's a big "if"—then you have it. It's already impressive enough for a small program; if you take something like ISE Eiffel, half a million lines of code developed over a decade, the result is amazing. I have the same passion for programming that I've always had, even if I haven't been able to write anything big myself in recent years, since it's a discipline that demands sedentariness and is hardly compatible with other activities of an entrepreneur-author-speaker. But I remain closely involved in the design of our products and especially of our libraries. One of the beauties of the Eiffel approach is that it breaks down the difference between analysis, design, and programming. The same tools and concepts are applied throughout. So I can use Eiffel to discuss a design pattern or other architectural issue during a whiteboard session at the beginning of a project, remaining very abstract since we're only starting, but already taking advantage of the precision, clarity and expressive power of the Eiffel concepts of data abstraction, genericity, multiple inheritance, and above all Design by Contract. Then if someone else among the people present goes out and actually builds the thing, it simply means adding more details, with the ability to go back and update anything, at any level, at any time. We call this seamless development and reversibility; some people also use the term single model principle. That's the way I see software construction. It's different from the standard view that creates artificial barriers between analysis, design, and implementation, with different notations and tools—say a UML-based CASE tool at the beginning and a programming environment at the end. I have never accepted that analysis should be noble and programming vulgar. The idea is to take advantages of the natural beauty, elegance, and conceptual power of the concepts of programming—to turn them into tools for designing and modeling, tools for adapting and extending previous achievements, and in the end tools for thinking.

Question: Do you view Eiffel as your most accomplished contribution to the industry? Are there any other contributions of which you're also particularly proud?

Answer: Basically, whenever I've found a good idea I've put it into Eiffel, so the question is almost self-answering. But it's important to understand what the word "Eiffel" means here. If it were taken to denote just a programming language, then the answer to your question would be far less clear; the language proper is only part of the solution. As I see it, Eiffel is the combination of a method, a language—not just a programming language, a modeling and design language as well—, a complete development environment, many library classes, and the constant focus on software reliability, on reusable components, on a seamless development cycle, on powerful interactive tools, on openness to the outside world, and in particular many other programming languages, on building software that's easy to change, systems that will stay around for a long time and grow as much as needed. With such a broad definition, it's not surprising that most of what I do falls into the same basket. Even the work into which I'm going now—component certification, developing fully proved classes—is part of that general effort.

Question: What brought you to design Eiffel to begin with?

Answer: Necessity. We needed a tool for ourselves, in line with concepts of modern software engineering, and nothing we saw was even remotely close, so we built it. This aspect of Eiffel has always been essential: It has to work for us. There's a big difference between tools that you build for the rest of the world to use, and those that you depend on for your own life. All our software is written in Eiffel. This has forced us to do it right.

Question: Compare Eiffel to other languages, such as C++. How do they differ? Does one offer certain advantages over the other?

Answer: Perhaps the first point to note is what Eiffel and C++ share: a central concern for performance. Like the designers of C++ and authors of C++ compilers, we pride ourselves on generating extremely efficient code. There is no significant difference between the execution time of C++ programs and those compiled with ISE Eiffel. Same thing for memory occupation, except that beyond a certain degree of complexity Eiffel wins, because in the end a computer, through a garbage collector, will inexorably do a better job than a programmer having to optimize manually the memory usage of every single part of a large program.

The more general comparison between Eiffel and C++ has been made many times, but it tends to be misleading since Eiffel pursues different aims. C++ and other programming languages, with all their qualities and limitations, are just programming languages—notations to express algorithms and specify data structures. Eiffel aims at a broader scope; it's a method for building systems—especially large, complex, evolutionary systems—and beyond programming it covers analysis and design through its principles of seamlessness and reversibility.

If you take the subset of Eiffel that addresses the same scope as C++—that is to say, the programming language—the differences are clear. C++ is an incremental update of C; it was meant to provide C programmers with object-oriented extensions. As a result, it still carries the C background, which prevents it from offering a number of O-O features that you find in Eiffel; for example, support for automatic memory management and garbage collection, so critical for large programs. The type system is also constrained by the C heritage; for example, you have all these basic types—integer, float, character—that sit outside of the class-based type system of an object-oriented language. In Eiffel, all such types are based on classes, providing more consistency and many practical advantages. More generally, Eiffel is not an upgrade to an existing language, but a design of its own—borrowing ideas from others, of course, but emphasizing the coherence of the overall construction, the simplicity of the language, the ease of learning it. The C++ choice of providing a smooth upgrade from C is understandable, and it has certainly helped the spread of object technology. But in the end, after the transition period, I think consistency wins. For example, in Eiffel there is an effort to provide one good way of doing anything that's needed, but not provide two if that can be avoided. In C++, because of the addition of O-O concepts to the C style, you can often hesitate between various styles. So if you want your program to call different functions depending on the runtime context, do you use a C-style array of function pointers, or do you rely on inheritance, overriding, polymorphism, and dynamic binding? In C++ you can do both, and it's not at all obvious, especially for a novice, which one is better. That can be very confusing.

Now, it's not hard to list technical differences. Eiffel has a built-in Design by Contract mechanism, with no equivalent in C++; this plays a key role in the Eiffel method for analysis and design, documentation, debugging, testing, project management. Eiffel's generic mechanism pursues the same aims as C++ templates, but in a simpler, clearer way and without the performance overhead of templates. The Eiffel form of multiple and repeated inheritance is, I think, easier to use and more consistent than the C++ form, which has caused many people to mistrust the very idea of multiple inheritance or even inheritance itself. C++ has C-style global variables; Eiffel instead enforces strict modularity, essential if you want to be able to modify large systems without letting any change anywhere trigger changes all over the structure. Eiffel has a notion of "once routine," providing a simple, effective mechanism for initialization and for sharing objects. C++ retains a number of C mechanisms, with no equivalent in Eiffel where they would clash with O-O mechanisms: type casts, function pointers, pointer arithmetic.

Question: How important is hands-on experience when it comes to learning a language, and how can those who don't have this experience gain it when they're first learning?

Answer: Any serious programming language also carries a certain culture with it, a certain way of solving programming problems. It's easy to identify a C culture, a C++ culture, an Eiffel culture. To learn the language is also to learn that culture, and you do that both by writing programs in the language and by studying good existing code. So, for example, to learn Eiffel, the books—Object-Oriented Software Construction, 2nd edition [Prentice Hall PTR, 2000, ISBN 0-13-629155-4] and Eiffel: The Language [Prentice Hall PTR, 2000, ISBN 0-13-247925-7]—are important, but the libraries are just as useful. EiffelBase, the library covering fundamental data structures and algorithms, is the prime source for such learning by example. It's Open Source, by the way, and available for download from http://www.eiffel.com/. Another one is EiffelVision 2, the multi-platform graphical library, providing the ability to design graphical applications with a single source code that will render the native look and feel under Windows, Unix, Linux, VMS. It makes extensive use of Eiffel's mechanisms, in particular agents, and is an excellent source of learning.

Question: 10 years ago, programming was supposed to become much more "object-oriented," and it was going to allow even non-techies to program. It seems that programming (whether in C++, Java, or another language) has become much more specialized. Do you agree? And, if so, how do you feel the evolution of programming is shaping up in terms of the next five years? What are your predictions for the future of programming?

Answer: The object-oriented mode of thinking has won. When it comes to serious, professional development, there is no credible alternative. Now, not everything that claims to be object-oriented implements the ideas well, and there are still major differences between approaches and languages. The Java or C# object models, for example, are different from those of Eiffel. But object technology, as a general trend, is the only game in town.

Programming is both less and more specialized. It's less specialized in that more and more people program, many of whom don't qualify as professional programmers. It's more specialized in that the professionals need ever more skills, if only to justify their status as professionals. This split will increase. The better the tools top programmers produce, the more impressive the results that non-top programmers, or non-programmers, can achieve. The more they achieve, the more they want to do, and the higher the pressure they put on the top programmers to produce ever more advanced tools and components.

As to what's coming next, the advent of the Internet has opened new horizons. We have been heavily involved in the Microsoft .NET technology, which is redefining the game. Most recent announcements from the other major players are mere attempts to catch up. Even the Open Source community is getting excited about it, which says a lot.

Looming on the horizon is the reckoning with the matter of software quality. The going has been so good that the software profession has been able to treat quality as one issue among many. Increasingly it will become the dominant issue. It's interesting to see how security concerns, for example, are bringing reliability problems to the forefront. If your program crashes because of a poorly programmed buffer, that's a reliability issue and so far wasn't sexy. But if a hacker exploits the buffer overflow to hack into systems through the Internet, people start listening. Aside from security, it's inevitable that trouble caused by bad software will make people start thinking seriously about quality.

A more mathematical approach is inevitable. Professional software development—not the everyday brand practiced by the public at large—will become more like a true engineering discipline, applying mathematical techniques. I don't know how long this evolution will take, but it will happen. The basic theory is there, but much work remains to make it widely applicable.

Question: Is there anything that's not happening in the programming industry that you think should be?

Answer: The industry as a whole is very cautious of anything that smacks of mathematics. That's very unhealthy. Programming is a practical, hands-on craft, but it's also in some ways a branch of applied mathematics; that inherent duality, a contradiction almost, is part of its charm. Too often we ignore or deny the mathematical part, without which we can't get the kind of quality that modern software will increasingly demand. We need more rigorous approaches. The math involved is not very hard—mostly high school or undergraduate level—and it can make a tremendous difference; we need to get rid of the instinctive anti-intellectualism and accept that mathematics, while not the answer to everything, is part of the picture.

Something else that's wrong is the chasm between industry and academia—far bigger, as far as I can judge, than in other disciplines. It's not clear which side is to blame. People in industry often have an instinctive distrust of academic research. People in universities, for their part, have not always contributed enough. In software engineering, most of the innovation over the past 20 years has come from industry. It's a compliment to industry, but it's also a sign that universities are not quite playing their part.

Question: Is programming an art? In other words, can anyone program?

Answer: Is writing an art? In other words, can anyone write? Is mathematics an art? In other words, can anyone compute? The questions and the answers are all more or less the same. Everyone can write, but not everyone can be a writer. If it's still less obvious for programming it's because not so long ago it was such a specialized subject that only a small minority had any idea of it. But today, yes, anyone can and increasingly will learn how to program at a basic level. Professional programming, however, is another story. Knowing arithmetic doesn't mean you're a mathematician. Being able to put together a GUI in Visual Basic doesn't make you a programmer.

The word art is interesting. There's definitely a trend to deny that part, to make everything logical and predictable. The very term software engineering reflects this goal, necessary and laudable. But for good software development, the artistic part is inevitable: the reliance on creativity, on beauty as a criterion of success. This is not necessarily a contradiction. Think of the work of an architect: You need excellent engineering, and you need a sure sense of aesthetics. It's the same for good software.

Question: In your opinion, how do your publications reflect your theories?

Answer: If they don't, then—given that I'm as much a writer as a scientist and engineer—they're a total failure. Of course there will always be, two days after you've sent a book to the printer, the question that someone asks and that makes you suddenly realize how you should really have explained a particular point, or reveals a key argument you forgot. Indeed, whenever I open one of my books or papers, I can't help thinking of how I could have said some things better. But setting aside limitations and imperfections, my publications are my theories. Tony Hoare wrote, in the introduction to his collected papers, that for him the process of writing is the research. Same for me.

Question: Do you have a favorite book or seminar that you enjoyed writing or teaching for a particular reason?

Answer: This interview. Okay, let me try again. It's very hard for me to teach or write something unless I enjoy doing it—I'm afraid that in the fortunately few cases I didn't, the result showed it rather visibly—so an easy answer is that I could name almost anything I've written or taught. But if I had to pick just one, I would cite my course "Object-Oriented Software Construction." It started out as a two-day seminar, and I gave literally hundreds of sessions, all around the world. Never once was I bored doing it. There is an inner beauty to the topic and the progression of the material, starting with a careful analysis of the issues to be solved and then bringing in answers, one by one, each addressing one or more of the previously identified issues, justified by clear logical arguments, and supported by decades of practical software development experience. At the end, it's like having put a puzzle together. Nowadays we give this course less often as a public two-day seminar, since people believe they already know about object technology. In fact they don't, and the seminar is as needed as ever, but of course the first rule of education, as any parent of a teenager discovers, is that you can't teach someone something he thinks he already knows. This is the one absolute, final, incontrovertible, insuperable obstacle to learning. We still teach the course in-house, and also have a five-day version that uses Eiffel as the vehicle and includes a strong hands-on component; at the end of the week people can go out and start designing and implementing serious applications using the full extent of object technology, Design by Contract, multi-platform graphics with EiffelVision, the Eiffel libraries, reusable software construction techniques, and the EiffelStudio environment, including its most advanced capabilities. That we can cover all of this in a week is due to a significant difference between Eiffel and many other approaches: the simplicity and economy of the method. In Eiffel, there's no need for gurus and language lawyers who are the only ones to know intricate details—basically because there are no such details. The course is very rewarding to teach because the sense of accomplishment is so palpable. You cover an elegant, consistent theory from beginning to end, and give students a range of practical skills that they can immediately apply.

Question: Of all of your different roles—author, consultant, professor, developer, speaker—is there one that you enjoy the most or that you find especially fulfilling? What about it do you most value?

Answer: You left out "entrepreneur." Since we started ISE in 1985 it has been the sole focus of my activity, and there is something profoundly rewarding in being able to bring your ideas to market and turn out a profit. There are other criteria of success—papers, books, talks, knowing that people do Ph.D.s based on your work, being high up in the citation indexes—but few in the end are as gratifying as your ability to sell your stuff to someone who feels it's making his life easier and his work better, and proves it by paying you real money. Another great thing about our company is that it's been a family business, with my wife Annie playing a strategic role right from the start, and our children closely involved too. What could be better than spending your life with the people close to you?

I like all the other roles you cite too. Speaker, for example. I've never understood how people can have stage fright. My only forms of stage fright are pre-fright, the fear that the previous speaker might continue talking, and post-fright, the fear that someone, sometime, might take the microphone away from me. But being scared of speaking? That's like being scared of making love. Author, that's something completely different; speaking is pure fun, but writing is work. I have produced lots of articles and quite a few books, some rather big, like Object-Oriented Software Construction, the second edition, thirteen hundred pages densely printed; but I still write painstakingly slowly because I keep correcting again and again. Once in a while, though, I reread a paragraph one more time, and feel that it's about right. That's the reward. One of the rewards, in any case. Good sales are another. Misunderstood genius writing for posterity? Thanks, but no thanks. Sure, I want to please myself, and I hope to please my peers, but mostly I want many people to buy and read my books. If not, why publish? You can just write a diary, or an email to your friends. So maybe that's my answer to "what do you most value about being an author." What I most value about being an author are the readers.

In the end, however, the most important role is related to the software my team has built. Little can compare to the pride of knowing that at any time day and night mission-critical applications are running, written with our technology, the direct result of our long hours at the whiteboard and the keyboard, of constant efforts at analysis, design and implementation in and for Eiffel. The world's leading futures exchange is using a price reporting system—the nervous system of the institution's operation—written in ISE Eiffel. Investment management companies manage billions of dollars using software written in ISE Eiffel. Large scale US defense simulations and climate simulations run in Eiffel. TV stations are broadcast with the help of ISE Eiffel. People's health claims for an entire country are processed by Eiffel systems. Projects worldwide use our compiler, our tools, our libraries. It's scary at times—these people trust their most important projects to us, what if we fail them?—but it's the highest reward I can think of for a software professional.

Question: What made you decide to split your time between academia and industry? Do you find it difficult to maintain a balance between your research career and your managerial career? What advice would you give to another person who's trying to do the same thing?

Answer: The relationship between academia and industry is not the same in computing as in other engineering fields. It would be wrong to assume that academia is more innovative than industry. Often, it's the reverse. Companies will take risks; universities are, deep down, fundamentally conservative. For example, one can't hear a professor who justifies a choice of introductory programming language by "everyone else does it" without feeling shameful for him. In the field of object technology, almost all of the innovation in the past 20 years has come from companies, often smaller businesses like ISE. In fact, after the initial ideas that came out of the University of Oslo back with Simula 67, I can't think of a major O-O contribution that originated in universities. That's sad.

And yet I'm becoming a university professor, while of course retaining my links with ISE. The reason is not just the prestige of the university, ETH—the Swiss Institute of Technology—and of the chair, formerly occupied by Niklaus Wirth, the creator of Pascal, Modula-2, and Oberon. It's also that I think the contribution of academia is essential. Although it's hard today to compete with industry for tools—writing a compiler is nice, but who's going to match Visual Studio or ISE Eiffel?—universities can do prototypes, show the way.

Industry is concerned with the way things are. Universities should concern themselves with the way things should be. Too often, they don't. In a vain effort to appear practical and industry-oriented, they sheepishly adopt the latest fad or standard, say UML or Java, losing all critical abilities. It's not right. Universities should rise above fashions and devise the best solutions.

One of the reasons I need more time in a university context is to start a Component Certification Center. While the only hope for software engineering is in more reuse, more components, the danger is to get a flood of components with no idea of how good or bad they are. It's critical to establish an independent certification agency. That's what I want to do, pursuing both the "low road" of a Component Quality Model to define the basic properties that components should possess, and the "high road," the more long-term effort of proving components correct, based on the ideas of Design by Contract. Industry collaboration is required, but a university seems like the right place to start such a project.

Question: We know how valuable your time is, but would you humor us by answering some non-traditional questions?

In one sentence, what are the most valuable words you would like to share with your audience?

Answer: To be careful with any deep truth that fits in one sentence.

Question: Who are your mentors, and why?

Answer: I have always had great admiration for the lucidity, intelligence, foresight, freedom of mind, style, wit, simplicity, elegance, depth, and lightness, allied with considerable personal and physical courage, of the great writers of the Enlightenment: Voltaire, Diderot, Montesquieu, Beaumarchais. When I was a child, I venerated great scientists of the past: Pasteur, Darwin, Einstein—who was both a student and a professor at ETH—Mendel, and such. In computer science, I've been influenced by some of the pioneering scientists who are also excellent writers: Hoare, Knuth, even Dijkstra. One of the greatest influences has been Jean-Raymond Abrial, the person who came up with, among other things, the Z formal specification language and the B method and tools. For a number of reasons, he's not as well known as his peers, but he has shaped the thinking of many people besides me, and established unique standards of intellectual rigor.

Question: What do you learn from programming that you can't learn elsewhere?

Answer: Very interesting question. Most of the time, since computing is still fairly new, we think of what we can learn from others. But in fact I believe good software engineers know a few things that others could learn from us. They certainly color my dealings with the non-computing world. For example, you can't be a good programmer without constantly bearing in mind the necessity of distinguishing between specification and implementation; but once you get this distinction, you start applying it to many different discussions. The idea of recursion is also a beautiful contribution of programming: not just recursive routines but recursive definitions, recursive data structures, recursive reasoning, recursive proofs. Although this pattern is rooted in mathematics, we've taken it much further in software. Yet another elegant concept is data abstraction. One more thing that you learn in software, sometimes the hard way, is how to cope with change. Change is at the center of our work; anything that we do, we may have to revise. It's not by accident that our field is called soft-ware. Constant, uncontrolled change is lethal, of course, so we have learned to manage change; this transposes to many other areas of life.

More and more, I find myself thinking about non-technical topics using ways of reasoning that I've learned in software engineering. There's a definite risk of nerdiness—you know it's time to stop when you want to precompile your taxes or reboot your spouse—but the intellectual modes of operation we've developed in our field can be fruitful elsewhere.

Question: Do you have any interests outside of the industry you work in?

Answer: Actually, no, I'm a total geek. Well, all right, not entirely. I would kill for Mozart, Rossini, Schubert, or Offenbach. I enjoy moving around the world—not just visiting, but staying. I have had the privilege of living in Paris, Santa Barbara, Melbourne, Zürich, Palo Alto, and Nancy, as well as Milan, Sydney, and Novosibirsk more briefly, and have enjoyed all immensely. I even enjoy the very process of moving. When I arrive I head straight to the opera and, jet-lagged, sleep through the first act, then really enjoy the rest. I've slept at all major houses: the Bolshoi, La Scala, the Met, Covent Garden, Sydney, the Dorothy Chandler Pavilion, the Stockholm Royal Opera. Learning a foreign language and discovering its literature in the original is also an irreplaceable pleasure. I could go on, but I'm not really answering your question, since none of this is "outside of the industry I work in." There's no firm border between inside and outside. What really drives me, other than greed, is beauty. Beauty can be in a geometrical proof, in an algorithm or its Eiffel implementation, in the indentation of an Eiffel class text, in the architecture of a library, in a design pattern, but it's not much different from the beauty of a Verdi chorus, a Mendelssohn finale, a Stendhal paragraph, a Monet landscape, a Japanese temple, a staging by Jean-Pierre Ponnelle, the glimpse of a woman striding at dusk along the Corso Buenos Aires.

Comment Author Replies Posted  RE: Interview with Programming Expert Bertrand Meyer alakhani 1 DEC 03, 2001 08:55:18 AM  Interview with Bertrand Meyer dominic.burford 0 DEC 03, 2001 02:25:23 AM

See All Comments