Opinions on Eiffel? Design by contract?

10 04 2007

Does anyone have any real-world experience or opinions on the Eiffel programming language and/or its design by contract features? Or with any other languages or tools that support this approach (especially for Java or via a JVM based language)? Or any good arguments against “design by contract”?

The reason for asking is that I’m currently re-reading Betrand Meyer‘s 1997 book Object-Oriented Software Construction, 2nd edition, and finding it absolutely fascinating, but it has left me wondering how its ideas have fared in the real world and what the counter-arguments might be.

For those who aren’t familiar with it, the book goes through the detailed rationale for an object-oriented programming language and the issues encountered and choices made along the way. It gradually builds this up into a complete language (and to a lesser extent, a supporting environment). Actually, it’s a thinly-disguised explanation of Meyer’s “Eiffel” language, but the discussions of the issues, alternatives and decisions are far more interesting than the specific syntax.

I’ve actually read most of this book before, many years ago, when looking for a book to help other people get started with object-oriented programming. This wasn’t the right book for the people I was trying to mentor, and at the time it seemed OK but didn’t really grab me. Somehow it got put to one side and become one of the few books that I never quite finished. I’m re-reading it now simply because I’m buying fewer and fewer books in these fast-moving, web-centric times, but still like to have a proper book to read before going to bed or when I can’t sleep. So I’m gradually re-reading selected old and “classic” books (which is an interesting and enlightening exercise in itself).

When I first read this book, I had done a couple of years object-oriented stuff in C++, was starting to use Delphi at work, was keeping an eye on Java (or maybe just starting to learn it), and had read things like the “Gang of Four” Design Patterns book. So I had a reasonable grip on object-oriented techniques, but didn’t really have any depth of experience with them. The book made some degree of sense, but seemed rather too academic and not as compelling as its reviews suggested.

A decade later, almost every issue discussed in the book seems to touch on something I’ve encountered or done battle with, and often casts a new light on it. It all seems far more relevant than before, and of course I can now compare it directly against the specifics of Java and my own experiences of using Java. In particular, there are lots of things in the book that ring a bell in the context of various recent and current discussions about Java (such as the introduction of generics, and how to support “properties”, and how to handle concurrency), or in the context of my own particular experiences over the past few years (such as the pain of writing natural-language Javadoc to specify method-argument validity, then needing code to check or enforce those pre-conditions, then needing test cases to check that code: all of which seems to cry out for a more formal, expression-based approach).

Overall, the book’s “design by contract” idea has substantial appeal for me, and feels like a good fit for things I’ve either been trying to do or been frustrated by for a long time. Many of the other ideas expressed in the book also look reasonable and potentially useful, or at least worthy of further consideration.

However, 10 years on from the book’s publication, and despite Eiffel still being a going concern (at Eiffel Software), and even recently becoming an ECMA and ISO standard, one hears almost nothing about it in the “mainstream”. Maybe it’s the fault of its licencing and business model (e.g. one supplier, single bundled development environment, expensive commercial licence)? It also looks like Meyer and Eiffel are now firmly committed to being “.net” based (with various sources such as entry QJVM of the comp.lang.eiffel FAQ and this discussion implying that the JVM is fundamentally unsuitable for it), which is a substantial deterrent to a Java dude like me.

So I’m curious as to whether anyone is really using Eiffel, or “design by contract” in general, and especially:

  • What aspects of it do and don’t work in practice.
  • Any counter-arguments to the book’s main ideas (especially “design by contract”).
  • Any views from anyone with strong experience of both Java and Eiffel.
  • What the state of play is for any other languages or tools that implement some or all of the relevant language features.
  • Whether there are any intrinsic reasons that some or all of these ideas couldn’t be supported by a JVM-based language, or whether .net is just Meyer’s particular platform of choice.

I guess this will either get no replies or degenerate into a language war, but you never know…

Advertisements

Actions

Information

3 responses

10 04 2007
Anon

I’ve played with Eiffel on and off since 1993 or so, and always regret having to come back to the languages I use in my day job (Java primarily). It’s a truly wonderful language to develop with, the defining characteristics (imvho) being first class support for design by contract and the consistency of the language as a whole (no primitive vs reference type nonsense, for example).

That being said I’ve never had the opportunity to use Eiffel in anger, and I think this is for two main reasons:
1. the class library (while reasonably extensive) just can’t compete with Java / Perl / wot-not
2. there is no reflection / introspection functionality

#2, while rarely needed in “normal” code, is very useful for infrastructure functionality (eg. Hibernate, AspectJ etc. wouldn’t be possible without reflection / byte code manipulation in Java) and I suspect it’s the partly to blame for limitation #1.

10 04 2007
Anon (again)

PS. Another area where Eiffel can’t compete is in concurrency. While SCOOP (at first glance) appears to be a pretty compelling model, the dearth of real world implementations (more than a decade after it was first proposed!) tend to suggest that something’s amiss (perhaps SCOOP isn’t as theoretically sound as the rest of the language).

Or it may be that the Eiffel ecosystem simply doesn’t have the development bandwidth to introduce such complex features. 😦

12 04 2007
closingbraces

Thanks “anon”. The consistency certainly seems very appealing after all the gunk of how Java primitives and arrays do/don’t mix with collections, generics etc.

On the other hand, whilst I can imagine visiting a language without reflection/introspection (or equivalent), I don’t think I’d want to live there full-time.

Haven’t read the SCOOP bits yet but it’s useful background to hear that there’s a dearth of implementations.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: