There must be many people who wish that Eiffel had won the object-oriented language contest against C++ and Smalltalk.

Some say that C++ won, not on its own merit, but because “the whole product” did what people wanted at a price they were willing to pay, whatever the relative worth of the core products Eiffel and C++. Although C++ became dominant, Eiffel is a much more interesting language and many developers like the precondition/postcondition checking that it does.

Throughout his career the language’s creator, Bertrand Meyer, has been among the most creative and experimental of program developers and is especially known for his introduction of Design by Contract, a technology for producing reliable software systems.

Originally developed for the Eiffel language, the concept of Design by Contract has influenced many other designs, in particular extensions to Java, C#, UML and the .NET framework.

Meyer, the author of 11 books including “Object-Oriented Software Construction”, one of the all-time best-sellers in computer science, has been the Professor of Software Engineering at ETH Zurich (the Swiss Federal Institute of Technology) since 2001. He’s the winner of numerous awards and honorary doctorates and was recently awarded 2.5-million Euros by the European Research Council to disprove the conventional wisdom that concurrent programming has to be horribly hard, by creating a better language for it. He wants to make this language simple and natural; a perfect assignment given the history of Eiffel.

RM:

Bernard, what prompted you to develop Eiffel?

BM:

Basically, it was an internal need. We had started a company in Santa Barbara called Interactive Software Engineering (ISE) while I was teaching at University of California and were developing a software engineering tool and we needed an environment to develop it in. I wanted an object-oriented environment but there was really nothing that was satisfactory at the time.

C++ existed but it wasn’t really my kind of field. I thought it was good as a stepping stone but not as an option.

SmallTalk was there too, but it was quite different, quite far from the kind of software delivering concerns that we had, so without thinking about it too much I jotted down a simple object-oriented notation.

I was very concerned about re-use so the first thing I did was to write the central primary classes and then we started to implement it. But as I say, it was for our own purposes, it was not meant to be a tool for others.

RM:

This was in the mid 1980s?

BM:

Yes, this was around late 1985 and one thing led to another. Eiffel was introduced to the public at the first OOPSLA conference in October of 1986 where it attracted considerable attention, leading us to release it as a commercial product at the end of that year.

I thought this was the state of the art but with real impact, no one else had anything that was helping to deliver impact at the time, so this is what the company then began to focus on then and what we have been focused on ever since.

RM:

Were there any especially difficult or frustrating problems you found when you were trying to develop it?

BM:

Well the problems tended to be more on the business side than on the development side or the organisational side. We did all the programming and then initially approached at least a first iteration. We then realised that you couldn’t have multiple inheritances unless you were willing to pay a negative price in performance, so we found out rather quickly that it was impossible to implement multiple inheritance in cost and time. This was when work started getting technical. The most frustrating part was getting the time system right – that has taken quite some time.

RM:

What was the reason then for building in pre-conditions and post-conditions into Eiffel?

BM:

Well to me it has always been obvious that you can’t write software without built in descriptions of the semantics of the software so it goes back to the work on axiomatic semantics by Dahl, Tony Hoare and Edsger Dijstra and others.

It was quite clear I think to anyone who was reading what was happening in computer science and working on program correctness that the semantics of a program should be expressed along with the programming implementation itself.

What people had not really done was to connect this to object-oriented programming, which is to say in a traditional say Pascal type of environment that it would be acceptable to have pre- and post-conditions.

In an object-oriented context you needed more. There was an article by Sir Tony Hoare which was about regarding proofs of correctness of the data repair foundations, Hints on Programming-Language Design, I think it is.

It is still a very interesting paper to read today and it was clear that this was a fundamental use for object-oriented programming. What we did was to bring these concepts to what we trying to achieve but also to develop the relationship with inheritance, to develop the relationship with exception handling, to emphasize the use of these constructs as tools for testing and debugging. I don’t think people had done this before, not systematically anyway.

A year earlier I’d started writing a book which started out as a translation of a book entitled Applied Programming Methodology and it used a kind of secure code to express algorithms and the programs. That application was not meant to be a programming language, a directly implementable programming language anyway, although it turned out to be very close to Eiffel as it emerged a couple of years later.

The notation had pre-conditions and post-conditions. I think this is the only way there is to talk seriously about program correctors and to build programs with a precise specification in mind. This was also connected to my work at the University of California Santa Barbara. I was teaching data structures and algorithms and it was very difficult to teach the topic without introducing notions of program correctness. So I also needed the notation in a way that I could use for that course, I had to use C which was absurd because C is not appropriate for this kind of teaching, so I developed code to create the algorithms before translating that into C for my students; that notation is also part of what eventually became Eiffel.

RM:

How do you feel about C++ having become more widely used than Eiffel?

BM:

Well it was a very clever make to C++ available to ordinary programmers and to their managers, because if you go back to the 1980s when Object Oriented programming exploded in use, it was still a very new function and people were scared of it. The original ideas were actually a bit rough and ready.

People thought it was something very strange which was going to disrupt all their practices, cost a lot of money and make all their current software obsolete and so on. It was a really clever move to tell people well, you can have object-oriented programming and C at the same time; you can keep everything that you have in C, in particular you can keep your property, the training of your programmers and the programmers themselves.

In this respect it was very useful and we considered that it was a stepping stone – a trade-off between two quite different worlds of C programming and the world of object-oriented programming, to have software like this it could only be a temporary step towards the full benefits of object-orientation, but it turned out to be much more successful than that.

I should also say that in terms of combining C with orientation, it couldn’t be done better and though C++ is now the ideal combination of C++ and object-oriented content it is so complex, much more so that it should be because it tries to do so many things.

The forces of complexity are very strong in the IT world when something is new, it becomes legacy and legacy is very difficult to get rid of – 25 years on we are then saddled with lots of C++ code which is raising lots of problems. Eiffel is a much more effective and scalable approach but it’s a little bit more difficult to explain and to sell.

RM:

An obvious question, why is Eiffel called Eiffel and why?

BM:

Well, it’s named after Gustave Eiffel who created the Eiffel Tower for the 1889 World Fair. It was completed on time and within budget, which was a great way of saying that Eiffel the language was as efficient. If you look at that wonderful structure, you will see a small number of robust design patterns, combined and varied repeatedly to yield an extremely powerful, bottom-up structure, exactly like a system built out of Eiffel Software’s reusable libraries.

RM:

What would you say you were proudest of in terms of the language’s initial development and continuing use?

BM:

It’s always the point when you release another iteration that you realize that the Eiffel community is still growing and developing. We were a very small company when we released the language. We didn’t have any support from a large business such as Ericsson, or Xerox, just a small team doing something different. The continued development is something for the Eiffel community to be proud of. To answer your question more technically really it’s quite a remarkable thing that we built a language right from scratch.

It’s definitely one source of pride. We knew that the code contracts might be copied like for example Microsoft’s code contracts have been copied, except that they are adding this to an existing framework which was not designed for it.

I’m quite proud of the exception mechanism which is not something that is as well known as it should be but I thought it was probably the first mechanism from a theoretical standpoint, the first conceptual demonstration that had these special cases and that handling exceptions could be done in a clean, rigorous way, closely connected with notions of program correctness. I still think Eiffel, for the work that it does, is quite superior to anything else that’s out there.

We need to talk about somewhat more recent developments, Eiffel introduced in 1997 an agent mechanism which is a way to combine the object-oriented framework with high level perfection objects representing what is called closures in functional languages. It’s completely type-safe.

It’s not familiar to most people. So initially users sometimes wonder what this strange thing is and then very quickly realize that the browsing mechanism gives you ways to explore the structure of a big, possibly complex software system very quickly and very effectively. Because there’s lots of complicated things that you can do in an object-oriented language with inheritance, there are lots of transformations that your operations or your methods can undergo and Eiffel Studio is quite good at giving you a handle on what happens to your methods and in helping you to transverse the software very quickly and very effectively, particularly in connection with debugging.

RM:

You mentioned Eiffel Studio, what’s the difference between Eiffel and Eiffel Studio?

BM:

Eiffel is the language a developer uses to write software and Eiffel Studio is the environment and toolkit that surrounds the Eiffel language.

RM:

What about automatic testing?

BM:

In the past four years or so, five years now, we have developed automatic testing tools which we don’t have any equivalent anywhere else as far as I know. The reason they don’t have any equivalent is that we rely on the presence of contracts in the code. So what it enables you to do is to take a set of classes and then push a button and have the classes structured completely automatically without the need to write test cases.

It produces the test cases for you. It’s called AutoTest and it’s an integral part of Eiffel Studio, which gives the power to the development environment which has no equivalent; it’s directly related to and dependent on the presence of contracts in the code.

RM:

Can you briefly explain to me about design by contract and how that works?

BM:

It’s a mechanism that supports the production of quality software. It ensures that your code will have substantially less errors because it follows ‘the rules’ of development. One way to describe this is to say that we keep asking three basic questions about software: what does it expect? What does it guarantee? What does it preserve? So what does it expect? That’s the pre-condition. What does it guarantee?

That’s the post-condition. Finally, what does it preserve within the class inheritance? So we keep asking these questions and as I said you start out your software development by defining these contract elements, pre-conditions, post-conditions and class inheritance.

It doesn’t have to be as strict, there’s no required order, so you generally think the way I described it, that is to say start by writing the contract and then write the code to fulfill those contracts.

You could also at the other extreme, if you are a very eager programmer, the hacker type who prefers to code things before thinking too hard about specification, you could also do it completely the other way round: write the code and then contract it.

The most common mode is to do the two more or less synchronously, simultaneously, that is to say write the contract, write code, add a bit of contract, and add a bit of code. So it’s not a constraining discipline but it’s a very useful one.

It has applications throughout software development as it helps you to do better analysis because you can use contracts long before you do any implementation to model the world, so as a kind of what people do with UML, you can use OCL as well, but it’s much more effective to do it in a precise formalism that can also serve later on as a programming language in Eiffel.

You can do it at the analysis level, you can use contracts at the design level to refine your design and make sure that it will satisfy and count all the stakeholder needs. Of course you use contracts at the implementation level and you can use them, as I mentioned, for testing, a key tool for testing and for debugging, it gives you documentation, essentially it gives you program documentation for free.

This is what some of the tools of Eiffel Studio do – they help to extract the contracts from the code and give you the documentation and you can use them, as I mentioned, to do exception handling as well as information in connection with contracts, but this is where the theory of exception handling comes from.

You can also use contracts to get your inheritance structures right and you can use them as a management tool to allow the manager to know what’s going on in the development at a sufficiently high level of instruction. And then there are more obligations, but overall it’s a metaphor that pervades through the entire software development process. It makes it possible to get a much better grip and a much better grasp on what you are doing as a software developer or as a manager. That’s the important thing.