Eiffel in a Nutshell

Here is what everyone needs to know about ISE Eiffel. You'll find lots more details in the rest of these Web pages. For the busiest of the busiest there is also the 1-minute summary.

After reading the present page you can use the complete Eiffel page to find links to many more detailed entries. 

What is ISE Eiffel?

Good question. Answering "an object-oriented language" is correct, but only part of the story. Eiffel is the only O-O language that also includes a comprehensive approach to software construction: a method, and an environment (ISE Eiffel).

The language itself is not just a programming language but also covers analysis, design and implementation.

What are the goals of ISE Eiffel?

ISE Eiffel pursues four major goals:
 
To give you a competitive edge by enabling you to get your software out fast.
 

To lower your maintenance and support costs by letting you produce bug-free software -- software that works the first time around.
 

To allow you to react quickly to market demands by producing software that is easy to change and extend in response to user requests.
 

To preserve your investment by giving you robust software that can be reused in many different developments.
 

What's so great about  ISE Eiffel?

In a few words:
The simplicity and power of the language and method.
 

Its seamlessness, providing a single thread throughout the software construction lifecycle.
 

The full application of object-oriented principles, distinguishing Eiffel from "hybrid" approaches. 

Eiffel's openness to the outside world, enabling it to serve a glue between software elements that may be written in many different languages (such as C or C++) besides those written in Eiffel. 

Its unique emphasis on reliability mechanisms, in particular through Eiffel's unique method of Design by Contract^TM.

In even fewer words: ISE Eiffel has a single purpose -- to help you complete your software faster, better, and at lower cost.

Is Eiffel intended for any specific application area?

Not really. ISE Eiffel has been used in many application areas, from financial applications to telecommunication systems. It is also widely used for teaching purposes. 

Eiffel shines particularly for ambitious systems that must be easy to adapt to changing market demands. With Eiffel you can quickly produce a basic version of a system, reliable and efficient, put it into users' hands early (while the competition is still trying to produce a bug-free "prototype"), and come up with new releases rapidly, all the time maintaining the standards of robustness that are the hallmark of the approach. 

Eiffel scales up. Many a 500,000-line system started as a 50,000-line program. Through its abstraction and structuring facilities, ISE Eiffel is one of the few environments that won't let you down when your project grows in size, scope and ambition.

OK, for a particular platform then?

ISE Eiffel is available for the major industry platforms: Windows (NT, 95), Linux, Unix (Solaris, SunOS, HP 9000, IBM AIX, Unixware, Silicon Graphics, Data General, Fujitsu, DEC OSF/1 etc.), VMS (Alpha as well as Vax). These implementations are all source-code compatible, making ISE Eiffel one of the most portable software development environments available today.

Must I forsake my existing software investment?

No. ISE Eiffel is an open system; it is at its best when used as a combination technology to reuse software components written in various languages. In particular, ISE Eiffel includes a sophisticated C and C++ interface, supporting: 

Calling C functions from Eiffel.
 

Accessing C++ classes and all their components (functions or "methods", data members, constructors, destructors etc.) from Eiffel.
 

Accessing Eiffel mechanisms from C or C++ through the Cecil library (C-Eiffel Call-In Library).
 

Automatically producing a "wrapper" Eiffel class from a C++ class.

What about run-time performance?

ISE Eiffel has shown that it is possible to utilize the full power of modern object technology without sacrificing run-time performance. Various benchmarks show run-time efficiency similar to C and Fortran, and in some cases better. Some problems still remain for certain kinds of intensive array computation, where optimizations are currently being implemented. For the vast majority of applications, performance is one more reason to use ISE Eiffel.

What is the "Melting Ice Technology"?

This trademarked name describes ISE's unique incremental compilation technology, which combines compilation (for the generation of optimally efficient code) with bytecode interpretation (for fast turnaround after a change). The bulk of your software, including precompiled libraries, is "frozen", i.e. compiled; what you change gets "melted", i.e. the compiler will quickly generate some interpretable "bytecode" and stop there, making sure that the frozen part calls the melted part (and conversely) when appropriate.

Is it true that Eiffel compiles into C?

Actually, the ISE Eiffel compiler generates, as just noted, an internal form known as the "bytecode". The bytecode, as was also noted, can be interpreted directly. But it can also be translated into other forms. 

To generate the final version of a system, the bytecode is optimized and translated into C, to take advantage of the presence of C compilers on just about every platform under the sun. This is the process known as "finalization", which performs extensive optimizations (routine inlining, static calls, array optimization), permitting the performance achievements mentioned above. 

Using C as an intermediate language takes advantage of the optimizations performed by C compilers and, most importantly, facilitates interoperability of Eiffel software and software written in C and C++.

What's ISE Eiffel written in?

In ISE Eiffel, of course. It is an example of a modern, ambitious system whose sophistication and flexibility require the best method, language and environment .

What about graphics?

ISE Eiffel offers a choice of graphical libraries. 

For portable developments, use EiffelVision, a high-level graphical library covering user interface objects (windows, dialogs, menus, buttons, dialog boxes etc.) as well as geometrical figures (polygons, circles and the like), which will run on all the supported platforms, adapting in each case to the native look-and-feel. 

For platform-specific developments, to take advantage of the full set of "controls" or "widgets" available on a particular window system, use the platform-specific libraries: 

On Windows, WEL (the Windows Eiffel Library) gives you access to essentially all the Windows graphical API, including the most recent Windows 95 and NT controls. A separate page describes how WEL combines the advantages of Windows and Eiffel. An extensive WEL tutorial is available on-line, as well as a general presentation of the design of WEL.
 

On OS/2, you can similarly use PEL (Presentation-manager Eiffel Library), whose design is very close to WEL.
 

For Motif (Unix), use MEL, the Motif Eiffel Library.

Using EiffelVision or one of the platform-specific libraries is not an exclusive proposition: you can mix-and-match the two levels, using EiffelVision for its abstract capabilities and, for example, WEL to take advantage of specific Windows controls. In fact, EiffelVision internally relies, for its implementation on each platform, on the corresponding platform-specific library, so you already have WEL if you are using EiffelVision on Windows.

What about relational databases?

ISE Eiffel provides the EiffelStore library for object-relational interfaces, with mappings currently available for ODBC (giving access to many dozens of database systems on Windows), Oracle, Sybase and Ingres. 

ISE Eiffel has also been interfaced with such object-oriented databases as Matisse (interface available from ISE), Versant and O2.

What does the environment look like?

It is described in detail elsewhere in these Web pages, but let's just say that ISE Eiffel is a fully graphical environment that includes all you would expect and more: analysis and design workbench with reverse engineering (sometimes called "round-trip engineering"), fast recompilation, editing, sophisticated browsing facilities, automatic documentation (see for example the descriptions of the "short form" below), an advanced debugging mechanism etc. 

Just as an illustration, without further explanations (which you will find by browsing around our pages), here is a screen from a debugging session:

What does an Eiffel program look like?

Actually we like to talk about "systems". A system is a set of classes, each covering a "data abstraction", that is to say a certain set of objects, from the external world or from the implementation. For example you may have classes AIRPORT, RADAR and RUNWAY in a flight control system, classes CUSTOMER and ACCOUNT in a banking system. In any system you can also have general-purpose classes such as LINKED_LIST and HASH_TABLE, although you would not normally write them but reuse them from a library such as EiffelBase. 

What does a class look like?

Here is the outline of a simple class COUNTER describing a counter: 
indexing
               description: "Counters that you can increment by one,
               decrement, and reset"

class
               COUNTER

feature -- Access

item: INTEGER
                      -- Counter's value.
feature -- Element change
increment is
                      -- Increase counter by one.
          do
                    item := item + 1
          end

decrement is
                      -- Decrease counter by one.
          do
                    item := item - 1
          end

reset is
                        -- Reset counter to zero.
          do
                     item := 0
          end

end


At run time this class will have instances: each instance is an object that represents a separate counter. To create a counter you declare the corresponding entity, say 

my_counter: COUNTER
create the corresponding object 
!! my_counter
(where !! is the creation symbol), and can then apply to it the operations of the class (its features):

my_counter.increment
...
my_counter.increment
...
my_counter.decrement
...
print (my_counter.item)
Such operations will appear in features of other classes, called the clients of class COUNTER. 

If you understand this example, you already know a fair deal of Eiffel! Note how simple the syntax is. Semicolons between instructions are optional (they have been omitted above); no strange symbols, no complicated rules. 

A couple more comments about this example: all values are initialized by default, so every counter object will start its life with its value, item, initialized to zero (you don't need to call reset initially). Also, item is an attribute, which is exported in read-only mode: clients can say print (my_counter.item) but not, for example, my_counter.item := 657, which would be a violation of "information hiding". Of course the class author may decide to provide such a capability by adding a feature

set (some_value: INTEGER) is
                 -- Set value of counter to some_value.
     do
                 item := some_value
     end
in which case the clients will simply use my_counter.set (657). But that's the decision of the authors of class COUNTER: how much functionality they provide to their clients. The indexing clause at the beginning of the class does not affect its semantics (i.e. the properties of the corresponding run-time objects), but attaches extra documentation to the class. Such information can be used by tools to help developers search for reusable classes. It is good practice to include at least a description entry providing an informal description of the purpose of the class.

A counter is great, but how do I write a real system?

The principles scale up. A class can represent a counter, but it can also represent an assembly line or a factory.

The Eiffel mechanisms for abstraction, reliability and simplicity provide a power of expression unmatched in the software world. 

What about reusability?

As Roland Racko wrote in Software Development: "Everything about Eiffel is single-mindedly, unambiguously, gloriously focused on reusability -- right down to the choice of reserved words and punctuation and right up to the compile time environment". We couldn't say it better. Eiffel was designed from day one to be the vehicle for the new software industry, based on the reuse of high-quality components -- rather than on everyone reinventing the wheel all the time. 

ISE Eiffel has put these ideas into practice by providing a rich set of professional reusable libraries (several thousand carefully crafted classes): EiffelBase, EiffelVision, EiffelNet, EiffelWeb, EiffelParse, EiffelLex, WEL, MEL, PEL etc.

What's this "Design by Contract" thing?

A revolutionary concept for building reliable software, introduced by Eiffel and only implemented in Eiffel. The basic idea is that to build reliable software it does not suffice to "be careful" and put all kinds of checks all over the text; a more systematic engineering approach is essential. You view your system as being made of a number of complementary components -- Eiffel's classes -- which cooperate on the basis of precisely defined statements of mutual obligations and benefits: contracts, as in contracts between two businesses. 

Alone in design methodologies and languages, Eiffel directly enforces Design by Contract through constructs such as class invariants, preconditions and postconditions. Assume for example that we want our counters to be always non-negative. The class will now have an invariant: 

indexing ... class
        COUNTER
feature 
         ...
invariant

        item >= 0

end

and feature decrement now needs a precondition, to make sure that clients do not attempt illegal operations. The keyword require introduces the precondition:
decrement is
             -- Decrease counter by one.
     require
             item > 0
     do
            item := item - 1
     ensure
            item = old item - 1
     end
The keyword ensure introduces the postcondition.

The precondition tells the client:

"Never even think of calling me unless you are sure the counter is strictly positive".
The postcondition says
"If you are good (i.e. observe the precondition) here is what I promise to do for you in return: I will decrease the counter by one."
The invariant adds the promise that
"Also, all my operations will maintain the counter positive or zero".
Preconditions, postconditions and invariants are called assertions. Assertions, of course, go far beyond simple properties of integers. For example:

A precondition on a file opening routine may express that the file must be readable.
 

A postcondition on a paragraph justification routine may express that all lines will have the same length.
 

An invariant on a class describing bank accounts may express that the current balance is equal to the sum of deposits minus the sum of withdrawals.

So the assertions state the semantic properties of the software and the external systems it models, independently of the implementation. Ironically, this gives Eiffel software, even though it is executable on a computer, more abstract expressive power than many analysis and design methodologies, which are unable to capture such semantic properties precisely.

Elsewhere in these pages you will find a more detailed presentation of Design by Contract as part of the on-line ISE Eiffel technology papers.

Assertions look nice, but how do they help me?

Assertions radically change the nature of software development. They have three major applications:

Design aid. By working with Design by Contract, you build software together with the arguments that justify its correctness. This makes it much more realistic to produce bug-free software.
 

Testing and debugging mechanism. Using the ISE Eiffel compiler, you select which assertions will be monitored at run time; you can set different levels (no check, preconditions only, preconditions and postconditions, everything) separately for each class. Then if an assertion is found at run time to be violated -- meaning a bug remains in your software -- an exception will interrupt execution. This is a tremendous help for getting software right quickly: testing and debugging are no longer blind searches; they are helped by a precise description both of what the software does (the actual executable texts, given by the do clauses) and of what it should do (the assertions).
 

Documentation. To give the users of a class a precise description of what a class provides, without giving out implementation details, you use the Eiffel notion of the short form of a class, which keeps the feature headers and comments as well as their assertions, but discards any implementation stuff. For example:

indexing
               description: "Counters that you can increment by one,
               decrement, and increment"

class interface
               COUNTER

feature -- Access

item: INTEGER
                       -- Counter's value.
feature -- Element change
increment is
                      -- Increase counter by one.
          ensure
                    item = old item + 1

decrement is
                      -- Decrease counter by one.
          require
                    item > 0
          ensure
                    item = old item - 1

reset is
                        -- Reset counter to zero.
         ensure
                    item = 0

invariant
            item >= 0
end
In the ISE Eiffel environment, you get the short form at the click of a button. The short form is an ideal form of documentation: abstract yet precise; and best of all, produced by the environment, not written separately, so you don't need to do any work to get it! No more need to write "interface modules" and then repeat their information in the implementation part.

What about inheritance?

Eiffel offers a sophisticated yet easy-to-use form of inheritance, enabling you to build new classes based on others. You might for example start from a class describing vehicles to write a class describing cars: 

indexing
               description: "Cars" 

class
               CAR

inherit

VEHICLE
               redefine register end
 
feature -- Element change
register (registration_date: DATE) is
                      -- Register for one year starting from registration_date.
          do
                    ... The specific operations for registering cars ...
          end
end

Does Eiffel support multiple inheritance?

Yes. A class can inherit from as many parents as necessary; for example a class COMPANY_PLANE will inherit from PLANE (describing the pilot's and passengers' view) and from ASSET (describing the accountant's view). 

In the Eiffel Library Kernel Standard, class NUMERIC describes objects equipped with arithmetic operations ("+", "-", "*", "/"); class COMPARABLE describes objects equipped with comparison operations ("<", "<=" etc.); then classes such as INTEGER and REAL inherit from both NUMERIC and COMPARABLE.

But isn't multiple inheritance complex and messy?

Not at all! Or to be more precise, not if it is done right. You will need multiple inheritance whenever you have to combine different abstractions, as in the preceding two examples and countless others. 

Eiffel tames the power of multiple inheritance through a renaming mechanism, which eliminates name clashes, and through a selection facility to remove any ambiguities resulting from multiple redeclarations. 

Without multiple inheritance you would lose much of the reusability benefits of the object-oriented method. For example not all comparable elements are numeric (think of strings) and not all numeric elements are comparable (think of matrices). Without multiple inheritance you would not be able to select one of these properties when you need to, and both when you need to.

What about repeated inheritance?

Repeated inheritance is the case, illustrated by the figure, in which a class inherits from another through two or more paths. Only in Eiffel can you decide separately for each feature of the common ancestor, such as birth_date or library_privileges in the example, whether it gives one feature or two in the repeated descendant. In the figure, a teaching assistant has the same birth date whether viewed as an instructor or as a student (one feature), but has different library privileges under each of these capacities (two features). This flexibility is indispensable to specify what you want to share and what you want to replicate.

Tell me about typing and binding.

Eiffel is statically typed to ensure that errors are caught at compile time, not run time. For example if your system may mistakenly try to execute a request to compute the diagonal of a graphical object that happens to be a triangle, the ISE Eiffel compiler will catch the error before it has had time to cause any damage. Most other object-oriented languages use some degree of "dynamic typing" in which such errors can escape the compiler. (Beware in particular of C extensions that are sometimes advertized as statically typed but still permit almost arbitrary type conversions.) 

Eiffel is dynamically bound to guarantee that the right version of an operation will always be applied depending on the target object. For example if you apply the feature "take off" to an object representing some kind of plane, you have the guarantee that if there are several plane types, each with its own take_off feature, the appropriate one will always be automatically selected. (In contrast, some approaches by default use "static binding", which can result in disastrously incorrect behavior.)

What is BON?

The Business Object Notation, an analysis and design method that is based on concepts close to those of Eiffel (Seamlessness, Reversibility, Contracting) and defines simple, intuitive graphical conventions. BON is particularly notable for its ability to scale up when you need to describe large and complex systems, keeping a view of the whole while zooming into the details of components at various levels of abstraction. Like many of the other concepts summarized here, BON has its own page; the method is described in a widely acclaimed book by the authors of the method. ISE's EiffelCase analysis and design workbench directly supports BON.

How did Eiffel come about, and what is its history?

Eiffel was designed at ISE in 1985, initially as an internal tool to develop some of our products. We wanted a modern, object-oriented environment integrating the concepts of modern software engineering, and there was simply nothing available. The ISE Eiffel 1 environment was first demonstrated in 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 1986. The technology spread rapidly over the following years, leading to a set of successful industrial projects in the US, Canada, Europe and the Far East. Right from the beginning ISE Eiffel also impressed the academic community as an ideal way to teach software concepts at all levels, leading to its adoption by numerous universities around the world as the primary teaching language. 

Successive versions of the environment appeared at the rate of about once a year. Eiffel recognition was given a large boost by the appearance in 1988 of the book Object-Oriented Software Construction by Bertrand Meyer, which quickly became the best-selling title in the field and was translated into eight foreign languages; the book used Eiffel as the natural vehicle to introduce concepts of object technology and Design by Contract. (The greatly expanded second edition is now available; you can find it in bookstores or order your copy from ISE.) 

The last iteration of the original technology was version 2.3, released in the Summer of 1990. The next version, ISE Eiffel 3, resulted from the lessons of the initial version and was written entirely in Eiffel; it was bootstrapped from 2.3. ISE Eiffel 3 introduced the Melting Ice Technology for fast recompilation, a fully graphical environment based on innovative user interface concepts, and considerable advances in libraries (graphics, networking...) and optimization of the generated code. The initial versions were available on Unix; since then they have been complemented by fully compatible releases on VMS, OS/2, Linux, and our best-selling Windows versions (Windows 3.1, Windows 95, Windows NT), making ISE Eiffel one of the most widely portable solutions in the software industry. 

The latest milestones in Eiffel technology is ISE Eiffel 4, a major new advance described in detail in other web pages. 

By the way, where does the name come from?

When creating Eiffel in 1985, ISE decided to pay homage to one of the greatest engineers of all time: Gustave Eiffel, the man who built the eponymous Tower in Paris, but also a number of other durable constructions such as the metallic armature of the Statue of Liberty in New York, the Budapest railway station and many others. 

The Eiffel Tower, built in 1887 for the 1889 World Fair, was completed on time and within budget, as will software projects written in Eiffel. And if you look at that wonderful structure, you will see a small number of robust, elegant design patterns, combined and varied repeatedly to yield a powerful, efficient structure -- exactly like a great Eiffel system built out of ISE's reusable libraries. Like many software systems today, the Eiffel Tower was initially conceived as a temporary structure; and like many a system built with Eiffel , it was able to endure far beyond its original goals.

What better symbol could there be of the engineering principles behind ISE Eiffel?

"Design by Contract" is a trademark of Interactive Software Engineering.