Hi Cynthia,
Thanks for your interesting question. It's interesting to me because
for the past fifteen years I have been developing software using the
Eiffel programming language.
Eiffel was invented twenty years ago by Bertrand Meyer, as a language
to foster software correctness and re-use.
Eiffel is a stronly-typed, statically-typed procedural object-oriented
language. It enhances software correctness by attempting to "engineer
out" as many sources of bugs as possible. For example, it was one of
the first mainstream languages to be garbage-collected and to offer a
wide range of dynamically-sized data structures. But that's not what's
special about Eiffel.
Eiffel pioneered the concept of "Design by Contract" - the idea that
you can include the specification of a routine together with the code
itself. Although this concept has since been offered as an add-on to
other languages, nowhere is it as effectively realized and as cleanly
integrated as with Eiffel.
Every routine can carry an explicit precondition and postcondition.
The precondition states under what conditions a routine can be validly
called. For example, a square root routine might require that it can
only be applied to non-negative numeric objects. The postcondition
specifies the result. For example, a square root routine might have a
postcondition specifying that the result squared equals the original
value.
There are also class invariants that must always hold (for example
"count >= 0"), plus loop invariants and loop variants to help ensure
that loops always terminate and produce the desired result.
The nice thing about Design By Contract is that it is well-integrated
throughout the language and the compilation process. The preconditions
demarcate responsibility between the programmer who designs a library
and the programmer who uses a library. No longer do the both need to
use defensive programming; and large applications suddenly become much
simpler. The contracts bind not only objects of the current class, but
also those of descendants. A descendant may offer a "better" service
by weakening the precondition or strengthening the postcondition, but
it is always substitutable. The contracts also integrate with
exception handling - a bug usually triggers a contract failure which
pinpoints the precise location in the code where the bug occurs (no
more endless hunting around with debuggers, memory checkers etc).
The syntax of Eiffel is very readable, though more verbose than most
modern programming languages. It favours readability and
maintainability even at the expense of taking more time to write the
first version. Eiffel programmers find the language a real pleasure to
program in.
So why hasn't Eiffel caught on big-time? It's hard to say for sure,
but there are a number of contributory factors. Eiffel appeals to the
modest programmer; the one who knows they can easily write bugs and
who actively seeks tools to help them write better code. It's not
going to be used by the "gung-ho" programmer who churns out code then
fixes bugs as they get reported by the end-users.
Eiffel also doesn't appeal to the project manager who produces screeds
of "bubbles-and-arrows" diagrams for management (in, e.g. UML) then
leaves the implementation problems to be sorted out by junior
programmers. In Eiffel, the contracts ARE the specification; all the
junior programmers need to do is to write an implementation that is
consistent with the (runtime-checked) specification.
So who uses Eiffel then? It's used for teaching in more than a handful
of Universities, of which two (ETH Zurich and Loria France) also
participate in compiler and language research and development. It's
used by a small number of software houses, such as Fury Software (a
game developer). But it's mostly used by very large organizations who
need to get a handle on their code, and for whom reliability is
essential. It's used for defense contracts, healthcare, stockmarket
analysis, cutting-edge financial applications such as derivatives
management, etc. For these organizations, Eiffel is so strategic that
they will pay around $5000 per developer for a commercial license.
There are also two open-source Eiffel compilers available. Once is a
simple but robust command-line compiler; the other is the same
software as the commercial version and includes a quirky but extremely
powerful and productive IDE.
So what does Eiffel code look like? I can't provide a full set of
examples with explanations in this answer, but here's a short excerpt.
It's the specification for 'prepend', one of the features ("methods")
of the STRING class:
prepend (other: STRING) is
-- Prepend `other' to `Current'.
require
other /= Void
ensure
(old other.twin + old Current.twin).is_equal(Current)
end
This is how you would see the feature when using the browser of the
IDE. But when you look at the underlying code you would see the
implementation too:
prepend (other: STRING) is
-- Prepend `other' to `Current'.
require
other /= Void
local
i, j: INTEGER
do
i := count
j := other.count
resize(i + j)
if i > 0 and then j > 0 then
storage.move(0, i - 1, j)
end
storage.copy_from(other.storage, j - 1)
ensure
(old other.twin + old Current.twin).is_equal(Current)
end
I trust this provides a feel for the "flavour" of Eiffel. If you have
any questions, feel free to request clarification.
Regards,
eiffel-ga
Links relating to Eiffel:
EiffelStudio commercial version:
http://eiffel.com/
EiffelStudio open-source version:
http://eiffelsoftware.origo.ethz.ch/index.php/Main_Page
SmartEiffel open-source compiler and libraries:
http://smarteiffel.loria.fr/
Eiffel Software Directory:
http://eiffelzone.com/esd/index.html
TeamEiffel blog:
http://teameiffel.blogspot.com/
38 Cool Ways to use Eiffel:
http://www.eiffel.com/developers/cool_things.html
Google Search Strategy:
eiffel -"eiffel tower"
://www.google.com/search?q=eiffel+-%22eiffel+tower%22
Disclosure: I maintain the Eiffel Software Directory and administer
the TeamEiffel blog, so my answer is not that of an unbiased outsider
(but you knew that already). |
