Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Why Eiffel Might Be Worth a Second Look

By Coryoth in Technology
Tue Oct 31, 2006 at 12:00:00 PM EST
Tags: Eiffel, EiffelStudio, Programming Languages, Software (all tags)
Software

Eiffel is one of those academic languages nobody uses right? Well, sort of. Certainly Eiffel has greater interest among the academic community than outside it, but then other languages like Haskell have far more academic interest due to their purity. Eiffel is a surprisingly pragmatic language, and as a result it does have a solid niche market in industry. Over the last few years, however, there have been some changes that make Eiffel a more interesting proposition - it might be worth a second look.


The Right Tool For the Job

Let's get this out of the way at the start: while Eiffel is worth a second look, it does depend on what you're looking for in a language. Eiffel fits in nicely as an alternative to Java or C++ for developing large applications. If you're leaving Java for more dynamic languages like Ruby then Eiffel isn't going to be for you - you can probably quit reading here. On the other hand if you're using Java for large scale projects and appreciate the discipline it imposes, then Eiffel is definitely worth more than just a glance. Eiffel was designed with a pragmatic eye toward the development and maintenance of large scale software systems, and is remarkably good at it.

What is Eiffel?

Eiffel is an Object Oriented language, akin to Java - If you know Java or C++ learning Eiffel is utterly straightforward. Eiffel has many of the same features as Java or C++, but often offers improvements. For instance Eiffel has garbage collection like Java, but has memory efficiency on par with C++. Eiffel's type system is stronger, more robust, and safer than either C++ or Java. Eiffel offers generics like Java (or templates in C++), but they are more naturally integrated into the language (Eiffel had generics from the outset) and much easier to understand and use. Eiffel has multiple inheritance like C++, but has a much more powerful system for dealing with the issues that arise - which is to say that multiple inheritance in Eiffel just works, and isn't something to avoid (quite the contrary, it is used regularly!). Eiffel also has some novel features such as expanded types (which offer a distinct improvement over primitive types and autoboxing), non-conforming inheritance (which allows for partial implementation interfaces, among other things), and agents, which allow for closures. The feature Eiffel is most known for, of course, is Design by Contract, which integrates pre- and post-conditions and class/object invariants into the language and aids in correctness and documentation of software. To get a feel for the look of Eiffel you can browse through some examples on LiteratePrograms, or this comparison of C++ and Eiffel for longer code samples. Eiffel has had most of these features for some time now of course - so what is it that makes Eiffel worth a second look?

Eiffel is Now GPL Software

A GPL Eiffel compiler, SmartEiffel, has been around for a while (and even sports a variety of interesting features not found in commercial Eiffel compilers), but recently ISE re-licensed EiffelStudio, their commercial Eiffel IDE, libraries, and compiler system, under a dual licensing scheme. EiffelStudio is now GPL software. The catch is that if you want to release software under a non-GPL license you have to buy a commercial license. Then again, given that a great deal of large scale software projects are bespoke systems that may as well be GPL, this isn't necessarily a loss for many cases. If you desperately need to sell your software and keep the source then EiffelStudio will set you back around $5000.

Aside from being free to use, making EiffelStudio GPL has also pushed development along. The upcoming release of EiffelStudio 5.7 (the first major release after going GPL) has a lot of significant improvements, and is, in my opinion, a much nicer system to look at and work with. The roadmap also has plenty of other new and useful features appearing in the not too distant future. EiffelStudio is a first rate IDE (download the preview releases of 5.7 and try it out), and GPL development has helped round it out and shave off many of it's niche quirks for a more mainstream audience.

Eiffel is Fast

One of the first things that Eiffel brings to the table over Java is raw execution speed. Eiffel compiles, via C, to native code, and in practice that means it has performance comparable to C. Compared to C++, Eiffel is on par speed wise, and uses less memory. Compared to Java, Eiffel is way ahead, both is speed and memory. And you get that sort of performance from a fully OO language complete with generics, garbage collection, and all the other sugar you would expect from a modern OO language.

The downside is that to get that sort of speed Eiffel uses C as an intermediary language, and that means compiling can be very slow. To compensate EiffelStudio has a very intelligent compiler system with so-called "melting ice" technology that means that you only need to recompile as much as was changed since the last compilation. That means that while SmartEiffel is slow to compile, from within EiffelStudio compilation (after initially compiling the project for the first time) is as fast (indeed faster in some cases) as any other compiler I've ever used.

Eiffel has Excellent Concurrency Support

One of the things that Eiffel promises to have in the near future is next generation concurrency support via SCOOP. Instead of implementing concurrency by traditional methods such as monitors, which were introduced by Tony Hoare way back in 1974, SCOOP is based on the CSP model of concurrency that Hoare developed through the 80s as a vast improvement over his monitor model. The result is an incredibly natural and easy to use concurrency system, with much stronger assurances, and amenability to static checking via CSP model checkers (which can verify the impossibility of deadlock, etc.)

How simple is SCOOP? It requires only a single new keyword: separate. The system works by allowing you to declare objects (or classes if every object of that class will always be separate) as being "separate". Objects that are separate may operate concurrently in different threads or processes (SCOOP is agnostic to the actual concurrency mechanism, and is thus also easy to port). Wait conditions are naturally expressed as preconditions on methods. That's essentially all there is to it - almost everything else is handled behind the scenes by the compiler: it just works. If that sounds too easy it's worth reading some of the papers about SCOOP to hammer out the fine details, or just looking at working examples, but in practice it largely is exactly as simple as I just described.

Given that computers are becoming increasingly multi-core, and concurrent programming is becoming increasingly prevalent, having a language with such powerful, yet simple and easy to use concurrency is a huge boon. Getting concurrency right has never been so easy. Unfortunately the full SCOOP system is still being developed. For now SCOOP is available as a library and preprocessor. SCOOP is expected to be integrated into the Eiffel compiler in the next year or so.

Eiffel Helps You Catch Your Mistakes

Eiffel's Design by Contract approach, with pre- and post-conditions is a great way of catching errors earlier by providing both a powerful test harness to isolate errors, and more explicit documentation of APIs. That, however, is just the beginning - once you start providing contracts for your code, you can get other benefits for free. The first major benefit is AutoTest. This is a new system (still being developed, but very functional already) that uses contracts as test oracles for completely automated randomised testing. You push a button and walk away, and AutoTest will fully exercise your code with randomised tests and provide you with a simple report of what went wrong. There's a pluggable system for generating test data, so you can use anything from purely random, to genetic algorithms, to systems designed to provide maximal coverage. And it really does work - AutoTest found several bugs in Eiffel's base libraries that had gone unnoticed for years. There is already an effort underway to integrate AutoTest into EiffelStudio itself.

The other option is ESpec, and in particular ES-Verify which, using a set of modelling libraries, allows Eiffel code to be submitted to automated theorem provers for verification. ESpec is in its infancy at this stage, but already looks impressive, and will hopefully merge with the Extended Static Checking project for EiffelStudio.

Miscellaneous Extras

Both inline agents and non-conforming inheritance are relatively new to Eiffel, and given how powerful and useful they are, they are worth checking out - if you bother to take a closer look at Eiffel be sure to read up on both. Eiffel also offers good multi-platform support: EiffelStudio is available for Windows, Linux, FreeBSD, Solaris, and even VMS (a MacOS X version is forthcoming), and because Eiffel compiles via C you can compile efficient binaries for whatever platform you wish (thanks to gcc). EiffelStudio also, conveniently, comes with an easy to use GUI library, called EiffelVision2, which supports both Windows and GTK+ (and MacOS X in the future). Alternatively you can compile Eiffel to .NET bytecode with EiffelStudio, or Java bytecode with SmartEiffel. In the case of .NET Eiffel is well integrated and you can easily use and inherit from .NET classes. In the case of Java you need an extra wrapper generating tool to use and inherit from Java classes, but it is easy enough to do.

It is also worth mentioning, at this point, that moving to Eiffel doesn't mean discarding an existing codebase. Eiffel has support for using C++ classes via Legacy++, support for wrapping straight C libraries via EWG, the Eiffel Wrapper Generator, can use Java libraries and due to .NET integration it can use C# .NET classes out of the box.

If all of this has piqued your interest, you can start with a quick introduction, a more in depth tutorial, or take a tour of EiffelStudio. It is well worth the look.

Please note that while this article happens to be about Eiffel, there are a lot of interesting languages out there that deserve a second, or in some cases even a first, look. Various other languages that I think are definitely worth the time taking a look at include: Ada, D, Lisp, Nemerle, OCaml, Scala, and Spec#. Seriously, all of those languages deserve a close look to see what they're really capable of, even the ones you may have dismissed in the past.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Scoop
o Design by Contract
o LiteratePr ograms
o comparison of C++ and Eiffel
o SmartEiffe l
o preview releases of 5.7
o Compared to C++
o Compared to Java
o CSP
o papers about SCOOP
o looking at working examples
o library and preprocessor
o AutoTest
o simple report of what went wrong
o ESpec
o ES-Verify
o Legacy++
o EWG, the Eiffel Wrapper Generator
o Java libraries
o a quick introduction
o a more in depth tutorial
o take a tour of EiffelStudio
o Also by Coryoth


Display: Sort:
Why Eiffel Might Be Worth a Second Look | 111 comments (86 topical, 25 editorial, 0 hidden)
too iffy (2.50 / 4) (#1)
by United Fools on Tue Oct 31, 2006 at 08:11:29 PM EST


We are united, we are fools, and we are America!
i prefer Lisp (nt) (3.00 / 3) (#2)
by circletimessquare on Tue Oct 31, 2006 at 08:48:00 PM EST



The tigers of wrath are wiser than the horses of instruction.

ror (3.00 / 4) (#4)
by the spins on Tue Oct 31, 2006 at 09:05:49 PM EST

the more i learn about aeronautical engineering, the more i come to see that most of you programmers are doing some real amateur hour shit.

 _
( )
 X
/ \ SUPPORT THE DEL GRIFFITH MODBOMBING CAMPAIGN

Excellent article (3.00 / 3) (#19)
by terryfunk on Tue Oct 31, 2006 at 11:42:50 PM EST

on a programming language I never tried.

+1 FP I enjoyed it.

I like you, I'll kill you last. - Killer Clown
The ScuttledMonkey: A Story Collection

Concurrent objects (3.00 / 6) (#22)
by GileadGreene on Wed Nov 01, 2006 at 12:48:14 AM EST

It's interesting to note that Alan Kay originally conceived the OOP model in terms of concurrent interacting objects (actors really - in fact Kay's early work on Smalltalk inspired Carl Hewitt's work on actors). Which is why you often used to hear (somewhat misleading) talk about objects in OOP languages interacting by message-passing. So CSP-based Eiffel concurrency is in some ways a return to Kay's original conception of OOP. Of course, it's also a vast improvement over more standard OO concurrency models, since it keeps threads of control aligned with objects (and thus able to be composed in easily understandable ways), rather than allowing individual threads of execution to wander through multiple objects (Peter Welch's Wot, no Chickens? has a pretty good explanation of why this isn't a good idea).

I evaluated Eiffel and didn't like it. (3.00 / 8) (#29)
by i on Wed Nov 01, 2006 at 05:14:31 AM EST

  • Unsound typesystem
  • Nonlocal validity which is sometimes enforced by the compiler and sometimes isn't (you can't tell when)
  • Multiple inheritance that is broken beyond repair (yes I mean it)
  • Other stuff that I don't remember
  • A vocal community which insists that every language bug is indeed a feature (look! pun!) (MI being the primary example) or, alternatively, a minor issue not worth anybody's attention

In addition, reading Object Oriented Software Construction left me with a remarkably persistent impression that its author is a pompous douchebag.

You may find the following little fact interesting. The Eiffel concurrency system SCOOP was first described in 1993, and its integration into Eiffel Studio is promised RSN ever since.

That was my experience, yours may be different.

and we have a contradicton according to our assumptions and the factor theorem

Can they do that? (3.00 / 3) (#31)
by creature on Wed Nov 01, 2006 at 07:28:20 AM EST

EiffelStudio is now GPL software. The catch is that if you want to release software under a non-GPL license you have buy a commercial license.

I thought you weren't allowed to impose such constraints, such are the wonders of GPL software. That was part of the deal with gcc - you're allowed to release software developed with it commercially (you don't have to GPL it).

I don't understand how they could GPL their software and impose this constraint.

Anyway, good article. +1FP when it appears.

So, a computer that ran only Eiffelware... (3.00 / 3) (#39)
by Russell Dovey on Wed Nov 01, 2006 at 10:56:24 AM EST

...a desktop computer, or server indeed, that ran primarily programs written in Eiffel, would be an...

EIFFEL TOWER! >.<

"Blessed are the cracked, for they let in the light." - Spike Milligan

-1, smells too much like fanboys. (2.37 / 8) (#48)
by ksandstr on Wed Nov 01, 2006 at 12:41:51 PM EST

"Compared to C++, Eiffel is on par speed wise, and uses less memory.", lol what. Unless you can run an Eiffel program without a stack, I hardly see it "using less memory" than a C++ runtime. What with the GC and all that.

Seriously though, what the other guy said about the unsound type system. Also, 1997 called, he's got a nice type inference regime he'd like to donate for y'all!

Far as I can tell, Eiffel is like Pascal, only wrapped in extremely verbose gobbledygook about contracts etc, and with heavier shackles and a cat-o-nine-tails with eleventy whips on it, and the safeword doesn't actually do anything. Snazzy name though. Too bad that the Eiffel Tower itself is an accomplishment that doesn't provoke oohs or aahs anymore.

While I don't disagree with invariants and pre- and postconditions as such, I feel that putting them at the language level and enforcing them with an iron fist results in a language that is painful, if not impossible, to refactor. What with the contract-declared internal APIs becoming huge, hairy scars as time goes by and more bits of the application come to depend on them.

Fin.

I'm curious (1.33 / 3) (#63)
by ElMiguel on Wed Nov 01, 2006 at 04:27:13 PM EST

What exactly is "worth the time" about Ada?

wait lets just use fortran 97 (1.40 / 5) (#71)
by newb4b0 on Thu Nov 02, 2006 at 03:38:05 AM EST


http://www.netmoneychat.com| NetMoneyChat Forums. No Registration necessary. Ya'll.

Name one app/system implemented in Eiffel. (none / 0) (#80)
by shm on Thu Nov 02, 2006 at 11:36:07 AM EST

I'm curious. Would I have heard of it or used it?


What's debugging like? (none / 0) (#86)
by jmzero on Thu Nov 02, 2006 at 04:54:15 PM EST

With the C-as-intermediate compilation, is there still a capacity for breakpoint/watch type debugging?  
.
"Let's not stir that bag of worms." - my lovely wife
Beats agile/XP voodoo, but... (none / 0) (#101)
by expro on Sun Nov 05, 2006 at 10:49:14 AM EST

Design by contract certainly beats agile/XP voodoo, but I'd be more enthusiastic about it with a C++-like const feature.  Many arguments have been made against const by Java and Eiffel advocates because they never got it, but none that seemed reasonable either in terms of why not or work-arounds.  Like all the Java arguments against templates, they should just fix it.

Another godlanguage article. (none / 0) (#103)
by 7h3647h32in6 on Sun Nov 05, 2006 at 02:47:16 PM EST

This is just another of the thousands of internet articles advertising the <insert language here> as having those: "Object oriented and portable like Java, and yet as fast as C" qualities that are the sure signs of having a homeboy author.

Truth is, I've never found a language that does both well.

Eiffel has no generics ... (none / 0) (#110)
by aos on Fri Nov 17, 2006 at 10:02:07 PM EST

Eiffel has templates, just like C++.

Java and .Net languages use generics, and yes, the difference between them are huge.

angel'o'sphere

Why Eiffel Might Be Worth a Second Look | 111 comments (86 topical, 25 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!