About Eiffel
Eiffel.com has a very marketing oriented text on why they think you should use Eiffel: http://www.eiffel.com/educators/why.html
Eiffel's creator Bertrand Meyer is somewhat dogmatic, but he has methodically shown his viewpoint of language design and software engineering in his tome Object-Oriented Software Construction (Prentice Hall, 2nd edition, approx. 1000 pages). It's a good read, if you have the time and the resources to secure a copy.
For many years, the commercial version of Eiffel has supported static typing, an interpreted bytecode virtual machine, native compilation modes, multiple inheritance, generics (similar concepts are called templates/parametric types/polymorphic types in other languages), virtual methods (on by default), automatic garbage collection, true AccessControlLists for class feature sections, and language clauses to encourage proper use of Design by Contract (class invariants, loop invariants, method preconditions and postconditions, which are forms of assertions) without the use of an outside library. Eiffel's assertion/logging facilities are similar, though not identical, to Apache's Java Log4J library. Eiffel doesn't appear to have deeply nested namespaces such as JavaLanguage's package naming scheme and CPlusPlusLanguage's namespaces. Eiffel requires the specification of a root class when executing a program. Though the mechanics are different, it is conceptually similar to JavaLanguage's specification of a class with a public static void main method. Eiffel has a different take on the prevalent method of exception handling that is promoted in many languages. Each routine/method has a rescue clause. In a rescue clause, either the original block can be started-over (retry) or an exception has to propagate up the call stack (no fall throughs or regular returns permitted). Eiffel doesn't provide automatic rollback of member variables to meet a class's invariants, if retrying.
It is hard to relate the shades of differences between various languages, since the same terminology is typically overloaded. Comparing and contrasting of languages can be good, but also bad due to prerequisite knowledge and forward references that abound. Regardless, useful knowledge can be unlocked that leads to levels of higher understanding. For instance the general subject matter of exceptions is interesting. Serious issues of ExceptionSafety plagued the CPlusPlusLanguage's standard library right before ratification (see Herb Sutter's books for details). The Memento DesignPatterns tries to address facets of the general problem. Certain transactional frameworks, such as Java EJB throw away particular object-instances when system related exceptions are thrown (i.e. EJBExceptions). Even still, the EJB programmer is still responsible for handling application specific exceptions, especially if conversational stateful session beans are in use. Though this paragraph may seem to make many tangents, it tries to capture a MetaIssue that most languages don't fully abstract away. For a specific application, additional idioms and coding practices usually have to make up the slack for solutions that are expensive to perform. Language designers only take performance hits for the all cases, when the benefit out ways the expense for most conceivable applications. Performance and correctness are just two engineering dimensions to balance, though high degrees can be typically achieved for both.
Eiffel doesn't appear to have become a widespread commercial success. It seems to have suffered from at least being "a little to ahead of its time". Bertrand Meyer is a contemporary of CPlusPlusLanguage's Bjarne Stroustrup, when in the early 80's a new breed of object-oriented languages were being developed from the early predecessors such as SmallTalkLanguage and SimulaLanguage. Another contemporary of the day, ObjectiveCLanguage (C with Smalltalkish OO extensions) is largely used within Apple's development environment.
Funny how IBM has bought Rationale (Rational Rose) and Borland has bought TogetherJ; I'm sure the enterprise editions of their Java IntegratedDevelopmentEnvironments will have UML modeling tools as part of the package. Eiffel's creator's development toolset has always included an OO case tool, long before the "3 objected oriented design/analyst" gurus standardized and went commercial.
Development Tools
Eiffel has commercial and OpenSource offerings. Though Googling works, sometimes a good directory is better. Cetus Links has proved to be impressive in some Programming areas in the past, though certain subjects need new diligent maintainers (what doesn't these days).
Tutorials
A quick search on Google uncovers those tutorials on the language:
Getting started with the Eiffel method and language
- The reference tutorial. Used by Eiffel software.
- Presents the syntax of Eiffel in a scientific way.
Short sample
Sometimes, the best way to describe something is the let the thing describe itself. So here is a rather self-explanatory piece of Eiffel code.
class ACCOUNT feature
balance: INTEGER;
owner: PERSON;
minimum_balance: INTEGER is 1000
open (who: PERSON) is
-- Assign the account to owner who.
do
owner := who
end
deposit (sum: INTEGER) is
-- Deposit sum into the account.
do
add (sum)
end
withdraw (sum: INTEGER) is
-- Withdraw sum from the account.
do
add (-sum)
end
may_withdraw (sum: INTEGER): BOOLEAN is
-- Is there enough money to withdraw sum?
do
Result := (balance >= sum + minimum_balance)
end
feature {NONE}
add (sum: INTEGER) is
-- Add sum to the balance.
do
balance := balance + sum
end
end -- class ACCOUNT Until someone add a home-made Eiffel sample, this piece of code was ripped from:
http://www.an.psu.edu/ojj/courses/ist-240/reports/spring2001/fa-cb-bc-kf/code/eiffel.html
