Eiffel In Our Business


Eiffel Outlook, April 1995.
This article summarizes the experience of the development of a large commercial software system at ULTER Systems Ltd. as an example of the use of Eiffel as the development language and the Eiffel compiler by SiG Computer GmbH. It explains why Eiffel was chosen as the main programming language for the project. It describes the Eiffel compiler by SiG Computer GmbH and our experience in its use for large-scale projects.

Why Eiffel?

Background: the project is intended to be a general solution for planning and marketing departments of media organization and advertising agencies. It is a tool for planning and optimization of advertising campaigns and television schedules. Besides a complicated planning and analysis engine the system is required to have a user-friendly window interface. Another important business requirement was portability of the system across different platforms. Among the potential target platforms were boxes running Windows NT and Macintosh computers, and also Unix boxes connected to X terminals.

At the beginning of the project, a careful consideration was made as to the choice of programming languages, techniques and platforms.

The specifics of our market is that the potential customers have good financial resources and can afford significant investments into computer hardware. Also, the cost of software for them would exceed the cost of hardware on which this software will be run.

The estimate about the staff needed to implement the project was about 10-20 developers.

It was expected that the software would extensively use client-server architecture and relational databases. An additional complication was that the potential cutomers were using different relational databases, such as Oracle, Sybase or Informix. It was unfeasible to require them to buy a specific database server to be able to use our applications.

A strategic decision was made to use object-oriented technology for software development.

Two programming languages were considered - C++ and Eiffel. The evaluation criteria consisted of the following parts:

  1. Portability of software was the prime concern;
  2. Computational efficiency and memory requirements; Learning curve for developers and the ability to hire already trained candidates;
  3. Reusability, interoperability and maintainability;
  4. Cost of development and maintenance.
Below is the comparison between Eiffel and C++, considering each part of these criteria.

The portability issue has two parts. One is the ability of programs to interact with parts of different platforms, for example with filesystems and window systems, and services, such as different DBMS's. All systems offer their "native" programmer's interface in the form of C libraries and include files. This seemingly gives an advantage to C++. However, interfaces for different platforms are largely incompatible and require an additional layer of code hiding this incompatibility.

The implementation of such a layer would have the same cost in both C++ and Eiffel. However, since the functionality of this layer is used everywhere in the software system, the cost of its use in development and its simplicity are the prime concern. It was reasonable to expect that an Eiffel class library would be easier to use than a C++ library, and thus to have less cost of use. As well, since it was anticipated that this layer will evolve in parallel with the main part of the system, problems of dependencies were also considered.

As an example, it is much easier to redefine the interface of child and parent classes in Eiffel than in C++ if the development of such classes is done by different people. In C++, to redefine an inherited function correctly, it must be explicitly declared virtual in a parent class. In Eiffel, no change in the parent class is required. When we consider organizational overheads of such change, we clearly see the advantage Eiffel offers us.

The easiest part of compatibility is hardware compatibility. Both languages offer good solutions for these problems, and we know many programs that work across an immense number of platforms. No language has a clear advantage in this respect, although C++ offers better flexibility with its basic types.

In general, Eiffel is clearly superior to C++ for solving compatibility problems and isolating the compatibility issues.

Efficiency in use of CPU time and memory was also given highest priority. It was anticipated that the computations would be a big obstacle for interactive users.

Considering the use of C/C++ vs. Eiffel it was concluded that it was inappropriate to use Eiffel as the language for computations. It was necessary to keep large amounts of objects needed for computations but invisible to the end users. The garbage collection overhead, comprized of time to traverse all these objects and memory use for object headers and descriptors in garbage collector tables made it impossible to use Eiffel for implementation of such objects. Also, the measurements made to compare the time of array access had clearly shown the advantage C/C++ had over Eiffel.

A decision was made to isolate the numeric part of the application from the interactive part. The objects and algorithms of the numeric part had been clearly defined and implemented in C (not C++). The interface between numerical library and Eiffel libraries had been defined and implemented.

Therefore, even though C was used as the main language for the numerical part, it was not an obstacle to the development of the rest of the system in Eiffel.

The real-world issues of learning curve and organization of development were also a strong push for Eiffel. Although there were a number of candidates already proficient in C++, actual staffing of positions with C++ people was not easy. A training in OOP/OOD and a particular language was a necessity no matter what language would be used in the project. It was clear that the expense to teach staff members the principles of OOD and syntax of programming language is much lower with Eiffel than with C++.

This article is not the appropriate place for advocacy of Eiffel vs. C++ in terms of reusability, interoperability, and maintainability, but both the author's experience and general opinion favors Eiffel over C++.

The cost of development and maintenance was obviously one of the most important aspects of the language decision. Eiffel offers a much simpler syntax. It also forces a programmer to use object-oriented design. From our experience, it is easier to formulate and implement classes in Eiffel. As well, Eiffel greatly simplifies the use of computer resources. The garbage collector takes care of freeing memory.

Memory management in C++ usually leads to one of two extremes: either to the need for all modules to know the internal information about who and when needs what objects, or to active copying of objects between modules to avoid this problem. The garbage collection in Eiffel elegantly solves this problem. Besides apparent technical advantages, it greatly reduces development and maintenance costs and the number of potential memory use problems.

The mechanism of assertions also has a great impact on the cost of software development, helping to catch at least 70-80% of potential bugs in the early stages of development. It also dramatically improves software quality.

The natural way of development of such a project would be development of several libraries. The simplest examples of such libraries are dabatase connectivity and a windowing library, belonging to the compatibility layer. Note that the windowing library also includes the part responsible for representation of complicated objects such as tables (spreadsheets) and graphs, and this part does not belong to the compatibility layer.

As a side note, the windowing library developed at ULTER Systems is called EPWL (Eiffel Portable Windows Library) and is now available as a separate product. It has been extensively tested and modified to adopt necessary changes and now is a robust tool for any Eiffel developer who needs to create portable and GUI-rich applications.

The disadvantage of Eiffel (or, to be more exact, of the Eiffel implementation that we used) was that it is impossible to create precompiled libraries in the way that developers use in C++.

However, the general conclusion from the cost analysis again leads us towards the choice of Eiffel.

After considering all of these factors Eiffel was the natural choice for the project.

SiG Eiffel Compiler Review

SiG Compiler is a command-line Eiffel compiler, which generates C code. It works on most UNIX platforms, as well as under DOS and Windows / Windows NT operating systems.

General description.

SiG Eiffel compiler is written in Eiffel itself, and as any Eiffel program, is very portable. It produces ANSI C code from an Eiffel 'project'. Therefore, to produce an executable from an Eiffel project, one needs a C compiler system as the back end to the Eiffel compiler.

The Eiffel system being distributed includes only a compiler, and it does not include such amenities as an interactive debugger, an integrated development environment or CASE-like tools.

Its runtime system consists of two layers. The first gives an interface to the produced C code, and the second gives an interface to operating system services, such as file i/o operations and memory management. It makes the Eiffel runtime system extremely portable and does not hinder the performance.

Currently, the following platforms are supported:

Windows NT is superior to Win32S as a target platform for Eiffel if the choice is limited by the MS Windows family of operating systems.

The compiler utilizes mark-and-sweep garbage collection strategy.

It brings an overhead of adding and removing objects described in the 'local' sections of features. Objects are added and removed to and from a so-called call chain each time a feature is called and the control is returned. This overhead is specific to the garbage collection mechanism, but not to the compiler.

Conformance to standards

One good side of Eiffel as a programming language is a high degree of standardization. The language has an exact syntax along with strict semantic rules.

However, along with some pure compiler bugs (some of them described in the 'bugs' section), there are some deviations from the Eiffel standard.

One of them is a quite innocent change in treating semicolons in Eiffel source code. While Eiffel standard is very strict about separating statements and assertions by semicolons, SiG compiler merely ignores them. Although any program conforming to Eiffel standards regarding the use of semicolons can be parsed by SiG compiler, the reverse is not true. A program that passes the syntax analysis stage of SiG compiler will not necessarily be compiled by another Eiffel compiler.

The following example can be compiled by SiG compiler:

   	i ; := i ;  + ; 1
   	j ; := j - ; i;
because the compiler ignores semicolons entirely in feature sections of class declarations.

Bugs.

By definition, any difference from documentation is considered a bug. Therefore, the previous section could be incorporated in this one. However, most of the problems presented in this section are less fundamental and have been corrected.

A quiz: What output will this program print?

	class HELLO
	inherit
	   BASIC_IO
	   end;
	creation 
	   run;
	
	feature
	   
	   run is
	   local 
	      a : REAL;
	   do
	      a := + 5;
	      put_int( a );
	   end;
	
	end -- class
If you used [now obsolete] version 1.2 instead of current 1.3, you would be slightly surprised by the result. It would print 0. After I checked the C code produced by the compiler, it turned out that it was calling function '+' that has never been tested because it 'seemed' obvious. This is the funniest compiler bug ever discovered by the author of this article.

There are several dozen compiler bugs that have been discovered by users. It is worth noting, hovever, that most of them are easily detectable and apply to unusual situations. Also, SiG Computer GmbH has been very responsive and has corrected most of them in subsequent releases.

Most of bugs in version 1.2.* do not exist in version 1.3.

Use and Performance.

This compiler has been used in a large project involving hundreds of Eiffel classes. It has shown itelf as a robust and scalable tool.

However, it is a memory hog. On a source code including about 600 classes it achieves satisfactory performance only with approximately 32 megabytes memory. For IBM PC 486 working under Windows NT operating system, the compilation time largely depends on the amount of available memory:

	Memory size		Full compilation time (hrs)
                                including C compilation

		16 MB			5 hrs.
		32 MB			1 hr.
Usual benchmarks such as the number of lines of code (LOC) translated per second cannot be directly applied to Eiffel compilers, because unlike compilers from many other languages, Eiffel compilation supposes (but does not necessarily include) the analysis of the entire class system being compiled.

As a general note, it is entirely possible to use the Eiffel compiler version 1.3 from SiG Computer GmbH as a tool for large-scale industrial software development.

Conclusion.

The author's positive experience with Eiffel and the compiler comes from his work as an analyst in a large software project. The project called MARS is being developed by Russian software shop ULTER Systems in Moscow. The software will be used by European advertising industry, including mass media and advertising agencies.

All trademarks here belong to their respective owners.

Special thanks to Mr. Klepikov ( klm@blaze.cs.jhu.edu ) for his interesting comments about SiG compiler and compilation of OO languages.

Igor Chudov
WilTel International
igor_chudov@wiltel.com