Fog Creek Software
Discussion Board

Eiffell: Pro's and Con's?

Please don't let this devolve into an (inevitable?) dogmatic discussion.

I'd like to hear the honest advantages and disandvantages of Eiffel from people who HAVE USED IT.

My undestanding is:

+ compiles to C source code.
+ compiles for Win 98+, Macintosh !!, Unix, Linux (wow!)
+ Easy to read (not sure of this yet)

- Lack of libraries
- Hard to find programmers
- Quite expensive for commercial tools (Eiffel Studio $5k or so), although Visual Eiffel is much cheaper.

Mr.Analogy (ISV owner)
Tuesday, August 17, 2004

Dude, you've been searching for a new language for like a year already. Make up your mind.

Mr. CTO (Decision Maker)
Tuesday, August 17, 2004

<grin> the curse of profitibility.  I have the luxury of taking this slow, but it's feeding my perfectionist flaws.

Actually, we are already proceeding with Delphi, but I was curious about Eiffel.

Mr.Analogy (ISV owner)
Tuesday, August 17, 2004

I've never used Eiffel.  But one of the big advantages of Eiffel is supposed to be that it incorporates "Design by Contract" principles into the language.

Since you're interested in Delphi, you might want to take a look at "Chrome" a soon-to-be-released Object Pascal clone that is actually a .NET compiler that operates in Visual Studio.  Chrome will apparently integrate Design by Contract principles into the language in a way similar to Eiffel.  See{DFA00D71-D5A4-40A3-9FD0-251899EB30D8}

The brilliant RemObjects guys ( are the ones behind Chrome.  Makes me confident that this is going to be a very cool product. 

Herbert Sitz
Wednesday, August 18, 2004

Chrome appears to be little more than smoke and mirrors.

Christopher Diggins
Wednesday, August 18, 2004

> - Lack of libraries
> - Hard to find programmers
> - Quite expensive for commercial tools (Eiffel Studio $5k or so), >although Visual Eiffel is much cheaper.

aka nobody uses it.

Eiffel is the object oriented language that Bertram Meyer invented and uses for his examples in his classic "Object-Oriented Software Construction". It's basically as good as the next OO language having all the features one would expect: multiple inheritance, generics, basic types are objects (if you expect that) ...

It also has direct support for Design by Contract type programming, ie. pre- and postconditions are/can be checked using language contructs. I've never really been able to see what's so special about that, as if you couldn't check conditions and invariants with if-statements... 

Oh, and it also uses ugly pascal type := assignment operators.

  - pleases you if you're really into tool based Design by Contract and worship Bertram Meyer.
- just as good as the next language

contra :
- nobody uses it.
- just as good as the next language, which some people actually use.
- ugly := assignment operator
- automatic "safety" features considered patronizing by many programmers.


Wednesday, August 18, 2004

Pre- and postconditions cannot be implemented using selection statements. You have seen OOSC II, now start reading it. Just to give you a hint where to look in your copy of the book, simple selections fail to provide the following: contract inheritance, old, functional contracting, document generation, recompilation with contracting switched off, avoidance of contract recursion, and more. Not to mention the problems with invariants, precondition weakening and postcondition strengthening.

You missed the point of DbC completely.

Karel Thönissen
Wednesday, August 18, 2004

Their are big advantages of built in DbC over ifs and asserts.

1) It makes Multiple Inheritance work.  Sure, C++ supports multiple inheritance, but most users avoid it in favour of simulated interfaces using abstract classes.  Eiffel's base libraries full and effective use of Multiple Inheritance is used.

2) The level of testing can be fully controlled.  You can turn off the checks for improved performance once a library has become stable.

3) DbC can be used and to capture requirements and constraints during the design stage and remain right through to implementation.  The BON method takes advantage of this.

4) Eiffel's documentation is based upon the contracts, and is very effective.

In many ways DbC is similar to TDD (Test Driven Development) only more mature and with tighter integration.

The big advantage of TDD is that you can make it work with almost any language, wheras DbC only really works with Eiffel.

However, DbC offers much more then TDD because it is based on strong mathematical concepts.  I think this is why Eiffel failed to be popular: it is just to mathematical.  Maths will never be mainstream.

Meyer discusses the TDD and DbC here:

Ged Byrne
Wednesday, August 18, 2004

>> You missed the point of DbC completely. <<

Sounds like someone got up on the wrong side of the bed :)

Could you give an example of something you can't do with "normal" programming constructs?

>>contract inheritance<<

if the pre- and postconditions checks are part of methods that are inherited,  they get inherited along with the rest of the method. In case I want to inherit pre- and postconditions separately from the actual methods implementation, I can can extract the checks, eg:

doSomething () {
. doSomethingPreCheck()
. doSomethingImpl()
. doSomethingPostCheck()

(sorry for the "." can anyone tell me how to add whitespace in posts?)

And then only extend the Impl method. This strategy will also take care of: document generation, precondition weakening and postcondition strengthening, by only extending the PreCheck() and PostCheck() methods.

>>recompilation with contracting switched off<<

I can take care of that with:

if (doChecks) doPreCheck()

It's a matter of taste: do I prefer to have my program configuration done by the compiler or by the program. In case of preprocessed languages, I could also use DEBUG to not have any of the contract checks in my binaries.

>>avoidance of contract recursion<<
not aware of that particular parlance, care to elaborate?

I don't see any reason for not being able to enforce invariants with "normal" language constructs...

I do see the advantages of having such things supported directly by the language (Ged summarized them nicely), I'm only saying that you can achieve the same effects with general purpose programming constructs.


Wednesday, August 18, 2004

DEBUG should obviously read #ifdef, too much cofffee, sorry.

Wednesday, August 18, 2004

Karel's right.  You've not understood DbC properly.  And nobody has mentioned Agents yet either.

If you must use an imperative language, then Eiffel is definitely one of the best available.

David B. Wildgoose
Wednesday, August 18, 2004

The problem with your solution of precondition inheritance is that you strengthen the precondition: if the precondition is part of the routine, then it is always checked along with the precondition in the heir. That is not type safe.

The heir should either meet the precondition of its own implementation, or that of the ancestor or both. However, requiring meeting them both is not correct.

I am sure someone is able to come up with something that implements precondition weakening correctly in say C++ or Java. Of course that is possible in any Turing-complete language. But that misses the point. The complexity of the code literally explodes. Good programmers do not triust their own discipline.

You also provide an example with contracts being separated out. Now instead of a single service in our interface we have 4: the original, the 2 contracts and the implementation itself. This works, but this will explode in the end.

Contract recursion: the phenomenon that routine #1 's contract code invokes other code that is protected by contracts, which in their turn invokes routine #2. This is automatically avoided in Eiffel by the rule that code invoked from contracts is not contract-checked. Contract recursion is a nasty problem to deal with.

Now you are saying that you can achieve the effects of DbC with nornal language constructs. Of course that is true for any Turing complete language (if only sometimes by building an Eiffel-simulator). However, this was not the tone that was heard from your previous post., and I quote:

<<It's basically as good as the next OO language having all the features one would expect: multiple inheritance, generics, basic types are objects (if you expect that) ...>>

<<- just as good as the next language>>

<<- just as good as the next language, which some people actually use.>>

You suggest that just because something can be done in a language, it must be a good language. You are still programing on the bare machine I must presume...

Karel Thönissen
Wednesday, August 18, 2004

invokes routine #2

should read

invokes routine #1

Karel Thönissen
Wednesday, August 18, 2004

> DbC [...] makes Multiple Inheritance work

You interest me strangely. Can you explain more?

Wednesday, August 18, 2004

*  Recent Topics

*  Fog Creek Home