This year I needed to do a project in a language that is both old and
notable but still understood as unusual and exotic: Eiffel. I did not
know Eiffel in the past and needed to learn it very quickly to do my
task. Hence this article is not about Eiffel itself, it ist about a
newcomers impression about Eiffel. I will be writing about the "classic"
Eiffel with EiffelStudio, not about SmartEiffel and other interesting
clones that surely also deserve a lot of attention.
The first thing that can be said about Eiffel is that this language is
not fragile, for sure. Once you write a working code, you can later
modify and reuse it without big risks to break everything by change with
unforeseen consequences. First, it is clear enough to read, has
generics since beginning and provides more precise access control than
just dividing into public and private. Second, language has a number of
semi - mandatory check statements: your are supposed to write that do
you expect from parameters, that do you expect after the method call and
that do you expect to be the same at all times (invariants). These
checks look like a tiny Unit tests directly in the program code. They do
more, however - they change your debugging process completely. In other
languages, you see improper functioning of the application (wrong
numbers in the output, skewed graphical object, etc) and work fixing
this incorrect behavior. In Eiffel, you see your checks and invariants
failing and work on making them to pass. This is true even if you are
not any Eiffel master (like me) and your invariants are totally basic.
One may see no difference between which problem to fix, but buggy
behavior is often more subtle to spot and difficult to understand.
Differently, the explicit check usually fails in a very clean and clear
way, with all variables plus stack trace ready for you to analyze. It is
especially easy if you have written these invariants yourself and not a
long time ago. From the other side, the invariant failure outside your
code may be much more difficult to understand so it is important do
document all non trivial checks and never join irrelevant conditions
with and – this makes difficult to find the real reason.
Eiffel also has comparatively less syntax noise, sometimes even several
lines of Java code are required where one in Eiffel is sufficient. Less
special symbols and curly braces actually make code easier to read even
for Java programmer that used to see them. Just loop construct initially
looked very unusual because it has no default place to increment the
loop counter (this must be done inside the body of the loop). In a first
day we produced quite many hanging errors with endless loops (no loop
variable advanced) but this problem passes very quickly. I also liked
multiple inheritance that looks a powerful feature seems not confusing
at all with this language.
I initially expected to find only very basic library support and was
surprised to find a complete GUI capable to do all GUI should do, object
serialization over network and even FOSS Goana project that looks as the
true beginning of that at the end became Tomcat and Glassfish for Java.
Unfortunately, while Eiffel itself is very easy to learn the system
library is a system library: if you do not know the needed function, be
ready to search for some time. Of course, you cannot as easily google
for Eiffel problems and code samples as you can do for C, Python or
Java, the language is not so popular, but we did found some answers to
our issues on a web.
Eiffel comes with FOSS EiffelStudio that appeared for me faster and more
responsive that Eclipse. It does provide real support for development,
having features like refactoring, method usage search or perfect
debugger. While not exactly small (still hundreds of megabytes with big
projects), it uses less memory than Eclipse. Still, being under GPL, it
offers many low hanging fruits for the coder who would like to
contribute to it. The most serious issues I noticed were total absence
of integration with code repository, missing possibility to launch more
than one instance of application at time and system output outside GUI
window under UNIX.
Another great Eiffel feature is that both language and system library is
- well, almost - cross platform. I did have a couple of bugs that made
GUI to behave differently under various operating systems, and you
likely cannot rely on Eiffel's "write once, run everywhere" as much as
you rely on Java Swing. Still, interoperability bugs are just bugs to
fix and the platform seems having a good potential to be cross platform
without having bytecode layer just for that.
So, can Eiffel come next after Java? Maybe. It is definitely not worse
as a language, it is almost for sure better and at least is not just
same Java again as C#. Also, Eiffel code is compiled into C and has no
bytecode layer that separates Java from the "C world" so strongly. It
may be an attractive alternative to try if your tasks require you to
stay in this 'C world' and you just want to have a more convenient
language rather than periodically switching into Perl, Python or
something similar. And having C layer allows to create executables for
ARM or even more exotic platforms; something that seems not working out
of box with EiffelStudio but surely deserves investigation. This may
allow to use Eiffel on Gumstix-like devices where currently Java is just
*very* “ok”, C is still a king and Linux is that's expected when you put
your device out of box. Eiffel is not lots faster then Java neither it
uses a lot less memory but it really seems a little faster and uses a
little less memory – this still leaves a great impression as Eiffel
provides more, not less programming comfort.