ISE Eiffel Goes Open-Source

At long last, ISE Eiffel has released their development environment and libraries as Open-Source software, as announced in their press release (ISE Eiffel). The project is hosted on a wiki at the ETH and includes downloads for the most recent builds and nightlies (for Linux and Windows). The ISE implementation is the only one that fully supports the ECMA-367 standard, released in June of 2005. The download includes all development tools and libraries.

This is the language that Java and C# should be chasing instead of just trying to be better than one another or C++. Their recent introduction of generics[1] as glorified preprocessors, in which generic classes don’t follow expected inheritance rules, is one such recent debacle. Eiffel is the one OO language that asks the question, “how can we make the language more expressive?” before asking “how can we make the compiler easier to write?”

Advantages of the Eiffel Method

Eiffel the language has several features that it is relatively safe to say neither Java nor C# will ever have:

Contracts

Eiffel software includes preconditions, postconditions, class invariants, loop invariants and all of the check and assertion statements found in other languages. Contracts are inherited and can be specified for deferred features (abstract methods). See the Design-By-Contract presentations for more information (DBC Part One and DBC Part Two).

Unified Type Model

There is only one type of thing: the class. There are no exceptions to this rule—no special constructs, no end-runs around hard-to-write compilers—just simple answers to tough questions. No boxing and unboxing, no casting and no copy/paste programming. No interfaces, structs, enums, delagates, C-style arrays and no special value types. Any class can be a value type by declaring itself as expanded and the naturally expanded types, like INTEGER, BOOLEAN, FLOAT and so on are simply optimized by the compiler. The magic happens in the compiler, though, allowing developers to inspect, use and design with INTEGERs in the same way that they design with LISTs, WINDOWs or other compound or reference types.

Multiple inheritance

As mentioned above, Eiffel has a unified type model, which means it has classes, but not interfaces. Interfaces are not needed because Eiffel has full support for multiple inheritance, which, despite protestations from Java and C# to the contrary, turns out not to be quite so impossible to realize after all.[2] Interfaces in other languages are crippled in that they don’t allow for default implementations and don’t allow features to be described with their contracts[3]. Simply inheriting from more than one class is much more intuitive and cuts down on repeated implementation.

True Generics

The generics recently included in Java and C# are a great improvment over the 1970s-style arrays previously available. They allow a much higher level of expressivenes and, most importantly, obviate a lot of iteration code and horrible, horrible casting. However, seemingly innocent limitations—like a lack of parameter covariance and lack of inheritance—cripple these implementations further.[4] Now that both C# and Java have some form of generics, we need to change the following clever tagline[5] from:

“OOP without generics is like a car that only turns left—sure you can go right, just do three lefts.”

to:

“OOP without parameter covariance is like a car that only turns left—sure you can go right, just do three lefts.[6]”

Because of this, the class models in Java and C# will also never offer another wicked feature of Eiffel, anchored types.[7]

Agents

C# has delegates, which correspond roughly to Delphi Pascal’s method pointers, whereas Java makes do with interfaces and anonymous methods in order to pass code around to be executed at a later time. Agents are full-blown routine objects, which can be referenced and created according to the very same static typing rules used for other software objects. See the ECMA specification for more information or Agents, iterators and introspection for a quite old introduction (from 2000).

Eiffel has many excellent online presentations illustrating Design-by-Contract and comparing itself to Java, C# and Delphi Pascal. They’re well worth a look.

Drawbacks of ISE Eiffel

There are some drawbacks to the IDE release, mainly for Mac users. The IDE runs under OS X and can produce even GUI applications using the EiffelVision libraries—but as X11 applications. These don’t integrate very well into OS X. However, given Eiffels vaunted interoperability with other languages, it should be possible to build program logic in Eiffel, gaining robustness and clarity from the design powers of the language, and to integrate those objects into OS X applications using Objective-C or Java (using JNI).

A note on C# 3.0

To be fair to C#, it doesn’t seem to be as content to linger in the past as Java. The Linq Project is a “set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations.” The C# 3.0 Language Specification (in Microsoft Word format)[8] describes the feature and its deep integration into the next version of C#. This feature is anchored by type inference, which allows develoepers to leave off explicit types in cases where the type is clear from the context. The lambda expressions available in C# 3.0 come from functional languages and allow chunks of executable code to be passed around a C# program (analogous to Eiffel agents, though not as flexible). The LINQ Project overview offers more details in a web page (instead of a Word document).

public void function f (A p1) {
  assert( f_precondition );
  do_f (p1);
  assert( f_postcondition );  
}

protected void function do_f (A p1) {
  // to be implemented in descendents
}