Viikon kolumni
Sami Kallio
Suuren suosion(?) saavuttanut viikon kolumni -sarja jatkuu taas.
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. Desing, 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 bus 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 Eiffeland 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
This article also appears in Eiffel Liberty at
http://www.progsoc.uts.edu.au/~geldridg/eiffel/liberty/v1/n1/tb/. Author's
address: be...@acslink.net.au.
--
///////////////////////////
/ Sami Kallio, s...@iki.fi