Eiffel: An Industry Experience

by Thomas Beale, Sydney, Australia

This note is adapted from an article posted on the comp.lang.eiffel newsgroup in 1997.

1. Introduction

Here is an industry experience slant on the Eiffel/Java thread

I am currently acting as a consulting engineer for a financial project which decided to go Eiffel, after an initial assumption that Java would be used.

I would say the project, while not representative of all project or system types, is certainly representative of a large class, viz medium size client/server business systems, containing GUI applications, reporting applications and rule evaluation.

An investigation was carried out, with the result of deciding on Eiffel instead. The reasons for going Eiffel were as follows (the decision was made early 1997, so some of the following regarding Java may be out of date):

2. Design, Modelling, CASE etc.

As a design formalism, Java is missing Multiple Inheritance (MI), genericity, and assertions. We use all of these extensively in the design sense.

Getting around a lack of genericity particularly makes a business object model a mess, not to mention what it does to the ease of implementation of even the simplest things. It also breaks type-safety, which is a real deterrent.

MI is also extremely useful, enabling inheritance by a class of: abstract business features, implementation(s), constants, access to shared objects, design interfaces (e.g. access to the database).

The availability of a CASE tool for Eiffel was also a factor in this category. Although it still has some rough edges, it has two features differentiating it from other tools: a) it implements a formal diagramming notation (BON) which is seamless with Eiffel, and b) it will faithfully reverse engineer any number of classes you put under it. This means it can be used to do forward-engineering of design ideas into code skeletons, and reverse-engineering from large libraries (either our own, or 3rd party ones). (It is currently not quite good enough to use in continual full-cycle sense, due to some technical problems). The result is that it is used for reviews and creating diagrams for design documents... diagrams you _know_ are correct.

Tools which use a mish-mash of Rumbaugh/Booch/UML etc. (remembering that this is all in the melting pot) have the disadvantage that the "formalism" used does not have a 100% unambiguous mapping to the target language (this may have changed with UML - I am not up to date).

In any case, we were unable to find any CASE tools which did Java, other than beta releases of what we took to be cosmetic changes to the C++ mode of operation.

3. Tools

The comparison between eiffel development environments and the available Java ones was stark. The system/class/feature browsing facilities in ISE eiffel (the one with which I am most familiar) had no equivalent in any Java environment. The tools area is obviously one of change... for both languages, so it seems likely that Java tools will improve quickly. However, the browsing mentality behind the ISE environment is superior in conception to what most other C-based language environments seem to offer, so I don't expect Java to be any better in this regard.

4. Libraries

We looked at existing Java products. The libraries were (compared to most Eiffel libraries I know of, and I suspect even any decent C++ library) very poor. Some basic data structures were not there.

The library is the real language you design and implement in, so it is (IMO) more important than the language itself. Consequently, extensive libraries programmed in a powerful formalism like Eiffel provide a more powerful language to work in. I have come to the conclusion that the use of formal software contracts in the library is the difference between a library you can trust and one you can't. So the existence of extensive libraries, implemented in a more powerful formalism was a clear winner over anything we saw in a Java implementation. I am not claiming, by the way, that the ISE libraries are perfect, or bug free. But the bugs I have found were found by .... turning assertions on at runtime. Draw your own conclusions.

5. Language

I won't bother going into the advantages of Eiffel versus the C-based languages - everyone should have read about them by now - except to say that genericity, MI, garbage collection, and software contracts were all factors in the choice of Eiffel. Over the period of development to date, we have also begun to use the Eiffel export facility extensively: I see it as a key way to develop groups of tightly bound classes forming a component/pattern/cluster. I would therefore suggest that those making language decisions include this useful feature in their reckoning.

More importantly, for a team containing some developers who had never worked in Object-Oriented before, technical reviews of both languages (by myself, and also published reviews, e.g. Ian Joyner's C++ critique), and anecdotal evidence (mainly from university professors), supported the view that the learning curve for Eiffel would be less costly. And this has turned out to be the case. After a short course and a very small amount of mentoring, hese developers are very productive; as consultant on the project, I am rarely asked questions about how to do something in the language. The questions I am asked are about more advanced things like modifying "once" objects, redefining export status etc.

I won't claim that Java isn't a _relatively_ easy to language to learn (it was certainly in the race, as opposed to C++ which is simply a liability for newcomers), but the semantic gap between what you want to express, and what you _can_ express is wider. Same old things: genericity, MI, software contracts, selective export.

The vestiges of the C type system that appear in Java were a further technical aspect detracting from the language. Being able to have a String and a char* is just confusing.

Another factor: Java is young, and we were not convinced that the language specification was not going to change.

6. Interfaces

Interfaces of interest included: object database, relational database, Windows GUI. All of these are available for both Eiffel and Java. Java certainly has more connections now to ODBs than Eiffel, but at the time of decision, there were only beta versions. In any case, you're only going to use one, and if it's of high quality, then that's the only one you need.

The Eiffel/ODB integration layer was not quite complete at the time of the decision (it is to a quite impressive database called Matisse), but we judged it was no worse than any of the extant Java/ODB integrations at the time. In any case, Eiffel had a relational database interface, which would act as a temporary fallback position. As it turns out the ODB path is proving fruitful...

7. Platforms, etc.

The criterion here was to run on Windows NT. Eiffel runs on all variants of Windows. The fact that it also runs on all Unixes that I know of is just a comforting thought....

Java, in theory, runs on everything, in JVM mode, and presumably will be available on most things in native mode, so this area was not particularly significant in the decision.

8. Industry Experience

All we were able to find in the way of Java was applets, applets, applets. I won't claim that there aren't any large systems out there, but none that we cound find out during a necessarily limited research timeframe. Anyone know of any?!

9. Summary

In summary, two words differentiated Java and Eiffel at the time of taking the decision, and I would be willing to bet still do: maturity and comprehensiveness.

The project team has not regretted the choice to date, and I don't see that changing.

If there is one thing to learn from this kind of experience (even if you are a diehard C/C++/Java person), it is: do NOT believe marketing hype. It makes fools of competent software engineers. Make a proper investigation, for YOUR project, with YOUR criteria, and decide using facts.

Of related interest

Author's address: thomas@deepthought.com.au.