Introduction to Eiffel

In the late 1970s, when I was a journeyman laboring over the macro assembler language, a simple, elegant, and expressive language called C emerged from the structured programming tradition. My friends advised me to forget C, to learn a “real programming language” like PL/1 or Ada, available on many more of the important platforms, and with commercial staying power due to the support of the government and major corporations. Ignoring this advice, I concentrated on C. Some of you may agree my choice was the right one for its time.

Now, more than a decade later, another simple, elegant, and expressive language has emerged, this time from the object-oriented tradition. With roots in Simula, beholden to no backwards compatibility issues, the Eiffel programming language was designed from scratch by Bertrand Meyer and his colleagues for the purpose of enabling the construction of robust, general, reusable software components. With commercial support from a few vendors, availability on several significant platforms, and some success stories in development of major commercial applications, this language bears careful observation.

I have known of Eiffel since 1989, when I read Dr. Meyer's book, Object Oriented Software Construction (Prentice Hall, 1988). I was impressed with the language, much as I had been impressed with C when I read Kernighan and Ritchie's classic, The C Programming Language (Prentice Hall, 1988), ten years earlier. The opportunity to give Eiffel a try presented itself with the Linux port announced in 1994 by Bertrand Meyer's company, Interactive Software Engineering of Goleta, California.

So what is all this noise about object-oriented programming, and what sets Eiffel apart from the pack of object-oriented languages?

Much of the promise shown by object-oriented software construction may be attributed to the possibility of code reuse, particularly the reuse of software components.

By reuse, I mean the incorporation of previously written software unmodified into new programs. In the US we have a saying: “if it ain't broke, don't fix it.” This folk wisdom highlights the result of research studies which indicate the great hazard of introducing new problems when working on existing software. Ideally, it should be possible to write something once, then put it on ice to be reused but never modified, except to fix bugs and perhaps to add new features. Existing users should be protected, if possible, from effects of such changes.

Unfortunately reuse has succeeded in only limited ways so far. For example, the Unix C library or the various widget libraries used in constructing Graphical User Interfaces are widely used across many platforms. These notwithstanding, most of the significant computer programs produced today contain great volumes of handcrafted code. The difficulty of producing software components with enough built—in flexibility is prominent—and a great part of this difficulty must be ascribed to language issues.

The Eiffel programming language was designed to promote re-use. Bertrand Meyer recounts in the preface to Eiffel: The Libraries (Prentice Hall, in press) how he started out to write reusable components and how he came to abandon the attempt to use existing languages and instead wrote a language for the purpose.

Compiled and strongly typed, with genericity (templates), polymorphism, dynamic binding, exceptions, garbage collection, a genuinely useful implementation of multiple inheritance, and unique handling of assertions, Eiffel should be considered a contender on purely technical grounds.

Eiffel provides assertions as language primitives that furnish both in-line design documents and optional runtime error checking. Assertions are inherited. This serves to guarantee that descendents will live up to or exceed their ancestors' promises. Use of these assertions is a part of what is called “design by contract”. These represent an application of responsibility-driven design at a language level.

There are also other factors:

The design of Eiffel has been placed in the public domain by Interactive Software Engineering, Bertrand Meyer's company. The Eiffel trademark is owned by NICE, the Nonprofit International Consortium for Eiffel, which has been liberal in bestowing use of the trademark. A validation suite will be available from NICE later this year. Major Eiffel vendors and users, including representatives from corporations and academia, are represented on NICE. Membership is open to any interested party. Proposals of NICE are published on the newsgroup comp.lang.eiffel. Anybody may participate in the ensuing discussion.

The official language definition is Eiffel: The Language, By Bertrand Meyer (Prentice Hall, 1992). Almost 600 pages long, this volume contains a precise definition of the language, many examples, and a great deal of discussion. The formal syntax definition occupies only eight pages.

NICE is in the process of standardizing the libraries. PELKS, the Proposed Eiffel Library Kernel Standard, is in the final stages of adoption, even as the vendors hasten to bring their own class libraries into line with it. Other libraries may follow.

Eiffel is available or announced from a number of vendors on a roster of operating systems or platforms including Windows 3.1, VMS, SunOS, Solaris, Ultrix, OSF/1, DG Aviion, IBM RS/6000, Silicon Graphics, Macintosh, OS-2, and NEXTSTEP, as well as Linux.

Many Linux users are interested in seeing vendor interest in our operating system, and a few astute vendors are beginning to join the fold. It seems not too surprising that vendors of a language that is in many respects years ahead of the pack should also be astute enough to recognize the nature of the Linux community. And they have—all four Eiffel vendors offer Linux ports.