eiffel vs ada

11.10: adda/lang/eiffel vs ada
Tucker Taft:
. pre- and post-conditions can be
fairly easily and efficiently included in Ada code.
Invariants seem difficult to emulate directly in Ada.
If you're really interested in the
formal use of assertions with Ada,
maybe Anna is a solution for you.

. although I like the assertion stuff in Eiffel,
I think the language has a number of "inelegant" aspects.
For example:
# exception handlers only at
the top level of a routine,
with the only way to "handle" an exception
being by retrying the whole routine.
# No way to return from a routine in the middle.
This makes it a pain in the neck
to search through a list for something in a loop,
and then return immediately
when you find what you want.
(I have never found the addition of
extra boolean control variable
a help to the understanding of an algorithm.)
# Namespace control
handled by a separate sublanguage,
and no real higher level concept of
"module" or "subsystem."
An obscure notation like "!!" (construction).
being used for an important and frequent operation;
# No way to conveniently "use" another abstraction
without inheriting from it.
# No strong distinctions between
integer types used for array indexing.
# Using the same operator ":="
for both (aliasing) pointer assignment,
and for value assignment,
depending on whether the type is "expanded."
(Simula's solution was far preferable, IMHO).
-- And most critically:
# No separate interface for an abstraction.
You can view an interface by running a tool,
but this misses completely the importance of
having a physical module that represents the interface,
and acts as a contract between
the specifier or user of an abstraction
and its implementor.
In Eiffel, one might not even be truly aware
when one is changing the interface to an abstraction,
because there is no particular physical separation
between interface and implementation.
I consider many of the above problems quite serious,
with some of them being real throwbacks
to the old style of programming languages
where there were no well defined
interfaces or modules.
I cringe a bit when people say
that Eiffel is the "most elegant" OOP
and that they would use it
if only it were practical to do so.
In many ways,
I think Ada is much better human-engineered than Eiffel,
with important things like range constraints
built into the language
in a way that makes them convenient to use.
Although general assertions are nice,
they don't give you the kind of
line-by-line consistency checks
that Ada can give you.
To summarize --
Although Eiffel certainly has a number of nice features,
I don't consider it ready for prime time
as far as building and maintaining large systems
with large numbers of programmers.
And from a human engineering point of view,
I think Ada is significantly better.
Eiffel targets a largely similar audience of
"correctness-oriented" programmers that Ada does.
However, it took some digging around
(no introductions to the language mention it)
to discover that Eiffel has a gap in its type system.
Guess what, type theory is a branch of math,
and OOP is a spiritual following.
I know what takes precedence in my book.
The Eiffel community's attitude is basically:
"we'll just pretend 2+2=5 because we can
use it to justify some teachings".
Ludovic Brenta:
I evaluated Eiffel too when I read Bertrand Meyer's
Object-Oriented Software Construction book.
The two things I dislike the most about Eiffel
are the lack of range constraints on numeric types
and the fact that almost all contract checks
are deferred to run-time.
- Ada has a built in concurrency model (like java)
and Eiffel does not.
In Eiffel there is SCOOP
(simple concurrent object oriented programming)
which tries to integrate concurrency into the language.
But there is not yet any Eiffel compiler available
which implementes SCOOP.
- Eiffel has "Design by Contract"
which is a very powerful mechanism to get your SW right.
Using assertions in your code appropriately,
you are able to catch a bug much closer to it's origin
than without DbC.
DbC opens up the road for a verifying compiler
(i.e. a compiler which can at compile time
verify if contracts are not broken).
I don't understand why the promotors of Eiffel
haven't made the language more complete
in terms of standardization,
standard libraries and concurrency.

Pascal Obry:
Ada even supports a Ravenscar profile
(where no dead-lock can occurs)
usable for high-critical systems.
1995 oop: programing by extension and dynamic dispatching
2005 oop: protected/tasking interface that can be inherited.

The ECMA Eiffel language specification is a well written document
(it is a language specification document
and not a document for the Eiffel user).
It lacks only in the area of
void safety, initialization
and covariant redefinitions (catcalls).
The problem:
It has not been updated since june 2006.
I.e. it reflects a status which has never been implemented
(and will probably never be implemented,
not even by EiffelStudio).
Eiffel`author Bertrand Meyer provoked by Ada.

(Yannick DuchĂȘne) a Ă©crit :
I talk to him (back in 1990 or 1991) one time:
the Eiffel inventor hates Ada .
. It appears that Meyer has some criticisms of Ada,
but I couldn't find anything that would indicate
that he hates it.
His Eiffel site has an article about the Ariane 5 crash,
but he said there that
the language couldn't really be blamed
because the problem could have been caught
using Ada's exception mechanism
if the programmers had used it properly.