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…