Eiffel: The language that OOP forgot?
by Joab Jackson -

Eiffel was one of the first object-oriented programming languages ever written, and is still considered by many to be the purest. Though it has never been widely used, some are finding Eiffel to be an increasingly appealing alternative in the face of the industry's increasing security concerns and the growing unwieldiness of C++.

Eiffel has a unique property, called Design by Contract, that proponents claim can be used to reduce bugs and avoid security holes. Also, since it started as an instructional language, it is pretty easy to learn.

Eiffel originated from a 1988 textbook on designing object-oriented programs written by Bertrand Meyer. Object-Oriented Software Construction is considered one of the quintessential texts on OOP. To explain the theories driving OOP, Meyer felt it necessary to write a language from scratch to illustrate his ideas. In the book's introduction, he explained that the existing OOP languages, such as Object-C, Object Pascal, Simula, and Smalltalk, couldn't fully convey the concepts of OOP.

Eiffel was a pure OOP language, not a modified procedural or general programming one. As such, it embodied Meyer's ideas of what made a successful OOP language, including such traits as modular protection from run-time errors, and modules with a clearly delimited syntax.

Saying bonjour in Eiffel

In Eiffel, class features are written in a basic "is ... do ... end" format. The obligatory "Hello World" program would work like this:

class HELLO

create hello
feature

   hello is
      do
         io.put_string("Hello World.%N")
      end
end

In this program, the first line defines the class ("HELLO"). The term "feature" declares that the services declared in this class are available to the clients of the class. The "is" introduces attributes, while "do" contains the heart of the routine. Multiple routines, which are called services, can be added into this class file.

Into this "is ... do ... end" template you can add assertions, which make explicit the contracts between the routine callers and the routines themselves, according to Meyer's 1990 book Eiffel: The Language. "Require," for instance, establishes preconditions that needed to be fulfilled before the routine can run. "Ensue" establishes postconditions, or what the routine must deliver when executed. Assertions are at the heart of the Design by Contract theory.

When I told Raphael Simon, the lead software engineer for Eiffel Software, I was calling from DevChannel.org, he commented on a discussion piece on buffer overflows he saw linked on the site. "We were laughing, because Eiffel can take care of that," Simon says. I challenged Simon to show how a buffer overflow exploit that would be possible in C would be eliminated by careful programming in Eiffel.

"Buffer overflows are due to programmers not checking if they did the buffer correctly," Simon says. A contract ensures that before a routine is called, certain elements must be in place.

Simon gave an example of how a program written in C could unwittingly execute a buffer overflow:

// Put "str" in "arr" at position "i"
void put (char **arr, int i, char *str) {
  arr [i] = str;
}

int main() {
  char *buffer[16];
  put (buffer, 17, "Out of bound");
}

In Eiffel the same procedure might be written this way:

put (arr: ARRAY [STRING]; i: INTEGER; str: STRING)
    -- Put "str" in "arr" at position "i"
  do
    array.put (str, i)
  end

main: INTEGER is
  local
    buffer: ARRAY [STRING]
  do
    create buffer.make (1, 16) -- Array lower bound is 1 and upper bound is 16
    put (buffer, 17, "Out of bound")
  end
In this example, "valid_index" is the following function:
  valid_index (i: INTEGER): BOOLEAN is
    -- Is "i" within the bounds of the array?
  do
    Result := (lower <= i) and then (i <= upper)
  end

Compiling this code, one gets a precondition violation in the routine "put" of the ARRAY class, Simon says. The precondition that will be violated is "valid_index: valid_index(i)." In this case, "lower" is 1, "upper" is 16, and "i" is 17. So "Result" returns as false, and the precondition triggers an exception.

In Eiffel, "you translate the requirements into specs," Simon says. "In Java, you have spec somewhere and code somewhere else. Eiffel puts it into the code. The run time will check the assertions."

The simple act of explicitly stating conditions between routines and callers promises dramatic results. Meyer, along with Jean-Marc Jézéquel, gave an example of how Eiffel's Design by Contract approach would have mitigated the run-time failure that caused the 1996 crash of the European Ariane 5 launcher. The pair laid out their argument in the Institute of Electrical and Electronics Engineers' IEEE Computer magazine, in the January 1997 issue on object-oriented programming ("The Lessons of Ariane").

The $500 million Ariane accident was caused by a software bug, namely an exception caused by a 64-bit integer erroneously converted into a 16-bit signed integer -- an action that should have been applied only to numbers less than 2^15.

A simple assertion to require that numbers passed to the subroutine be less than 2^15 could have been turned on during testing or even during actual program execution, raising a flag if it were violated, Meyer and Jézéquel wrote.

"Even when it's impractical to write all the contracts down, the discipline of Design by Contract helps a lot in thinking about your programs and writing clearer code," writes developer Franck Arnaud, a member of the board of the Nonprofit International Consortium for Eiffel (NICE).

Why Eiffel?

"In many ways, Eiffel is still ahead of its time, as the software development industry has not yet adopted the mindset needed to mass-produce high-quality reusable component," Todd Plessel wrote five years ago in his white paper "Why Eiffel?". "There are newer object-oriented methods and programming languages but they lack strong support for software quality compared to the Eiffel approach."

When compared to Eiffel, C++ comes up short for a variety of reasons, Plessel wrote. One is C++'s complexity. Even seasoned C++ programmers don't understand the whole language. It "harbors many subtle interaction complexities in areas such as inheritance, templates, exceptions, and object construction and destruction," Plessel wrote.

As for Java, Java programs just do not have the speed of programs written in compiled languages. Eiffel adherents point their language's multi-platform capabilities. Unlike the Java approach of compiling once and running the program on a virtual machine, Eiffel users write one set of code and then compile it for different platforms.

Typically, the Eiffel compiling process generates C code. Only the resulting run-time code has to be ported to specific platforms, making Eiffel easily portable to a wide number of platforms, Simon says.

Eiffel also supports multiple multiple inheritance. Inheritance allows services of one class to be utilized by another, as those services offered by that object's predecessors. Multiple inheritance allows an object to draw from multiple classes. Multiple inheritance is also offered by C++, though it is not very well implemented, according to some observers.

Another advantage to Eiffel is that the language is easy to read. One programmer I spoke with said he first learned Eiffel by accident. He was reading through Object-Oriented Software Construction to learn OOP, and by working through Meyer's examples, he had found by the end of the book he had inadvertently learned Eiffel.

Eiffel's simplicity also eliminates the need for external designing tools such as Unified Modeling Language modeling software. When using a graphical development environment, this can be a real advantage.

"If you have a large project, you start a case tool in English to get the basics for classes. When you start the writing the code you have the classes already set up. You don't have to toggle back and forth between other tools," Navickas says.

Developer Berend de Boer, who maintains a number of Eiffel open source libraries, uses Eiffel daily, mixing it in with Unix shells, Makefiles, XSLT, C (for Eiffel wrappers), an Xplain database, SQL, and JavaScript. He writes Eiffel code with Emacs and compiles it using Eiffel Software's compiler.

De Boer works for Parnell, New Zealand-based XSol, which developed a suite of business process management programs called "On Demand/Integration." De Boer is developing the agents and architecture necessary to do two-way data integration with all kinds of systems.

At first, de Boer thought he would use Delphi for the job, but Eiffel fit the bill perfectly. It was cross-platform, and could compile to native code. He could also distribute a binary that did not require dozens of libraries, a problem he would have faced with scripting languages.

"Java is cross platform as well of course, but it was deemed to slow. And it did not have generics or multiple inheritance," says de Boer. "C++ was never even considered."

"I think the big advantage of Eiffel and in particular [Design by Contract] is that it gave me confidence," de Boer says. It allowed him to write a mechanism that stored XML in a database with an XPATH parser on top. He doubts that he could have implemented that correctly using Delphi -- at least not with the same confidence.

"I know it works, that invariants are obeyed, preconditions met and such," de Boer says.

Why Not Eiffel?

All of these advantages raise an interesting question. If Eiffel is so superior to other languages in so many ways, why is not used more heavily?

I asked Eric Bezault this question. Bezault is the keeper of the Gobo library, the rough equivalent of the C++'s Standard Template library for Eiffel. Bezault points to several reasons for Eiffel's limited popularity. First is the lack of a heavy marketing campaign. Java, for instance, was pushed heavily by Sun Microsystems.

"With a lot of dollars you can more easily convince people that your technology is better than the competition, sometimes turning deficiencies into marketable advantages," Bezault says.

Another problem is the relative lack of class libraries, a problem Bezault admits is a chicken-and-egg dilemma. Developers are hesitant to work on Eiffel, given the relatively small number of libraries available. But without lots of developers working with the language, the libraries are slow to grow.

All of which leads projects managers to be hesitant about using a novel language. To modify an old saying, you can't get fired for using C++ (or Java, for that matter). "If [a manager's] project fails, they don't want to be criticized for having chosen a niche technology," Bezault says.

Some Eiffel tools

Niche it may be, but there are at least three development platforms available for Eiffel: Eiffel Software's EiffelStudio, Object Tool's Visual Eiffel and SmartEiffel. All of them have free versions.

EiffelStudio is perhaps the implementation most geared for commercial use. Although the full studio version costs $4,799 per copy, Eiffel does offer a free version for noncommercial use for both the Linux and Windows platforms, with a Macintosh beta recently released. The free version of the program doesn't have some features, such the ability to diagram the code, export the documentation, or compile metrics on the numbers of classes used.

Installation is pretty straightforward: Download, unzip, and compile. When building projects, each class is kept in its own file, a plain text file with a .e extension. Eiffel keeps a compilation control file called .ace. There are also files for simple version management and for diagramming code.

The layout of the EiffelStudio is that of a typical integrated development environment. The default configuration features four development windows. An upper left-hand block gives you the editable code. The upper right-hand breaks down the class by features, which allow you to jump around the large classes quite easily. The bottom right box is a diagramming tool.

The program features browser-like functionality, allowing you to jump back to former views. You can even bookmark places in the text. You can search a project for classes, and classes are also hyperlinked.

Visual Eiffel is another graphical developer environment, offered by Newton, Pa.-based Object Tools. A light version of Visual Eiffel for Linux or Windows can be downloaded from the company's Web site.

Prices for the full version range from $100 U.S., for the Personal edition, to $900 for the Power edition, which allows users to create ActiveX and COM components from Eiffel.

SmartEiffel is a strong command-line compiler for Eiffel. SmartEiffel falls under the GNU General Public License, as do many of the libraries provided that help to build the compiler itself.

In an effort led by Dominique Colnet, SmartEiffel came to life (originally under the name SmallEiffel) as a research project of LORIA, a joint computer science research center in Nancy, France. The project began in 1994 and saw its first release in September 1995.

Once unpacked and compiled, SmartEiffel leaves a set of executables in the its bin directory. Using SmartEiffel, a coder can compile a program directly from the command line, as well as translate the program into C or Java byte code. There is also a feature that allows Eiffel routines to be called from C code, as it is also possible to call Java and C routines from Eiffel code itself.

Despite the breadth of available tools, Eiffel advocates have a hard road to travel to find a wider audience.

"Technically speaking, Eiffel is pretty appealing. Technical people are pretty easy to convince. They see the advantages of the language," says Bill Navickas, who heads up marketing for Eiffel Software. "The managers are harder to convince. It is a political decision."

--Joab Jackson



[ The archive || [E-mail]