Isn't Ada less "elegant" than Eiffel?

Mildred Ki'Lya ml.mildred593 at gmail.com
Fri Feb 12 16:16:19 UTC 2010


As you all know, Lisaac is derived from Eiffel and share some of its
specificities.

I'm currently working with another language, Ada, and I found this
interesting.
Source: http://www.adahome.com/FAQ/programming.html#elegance


      9.4: Isn't Ada less "elegant" than Eiffel?

While it is true that programming-language support for "assertions" is
an important contribution of Eiffel to software construction, this is
not an issue of "elegance", and there are many other important factors
to consider.

Note also that preconditions and postconditions 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.

(Tucker Taft comments)

I guess one thing that bothers me a little is that people are quick to
say that Eiffel is "elegant" without really looking at it. I fear that
such statements will become self-fulfilling prophecies, with those
programmers interested in elegance migrating over to Eiffel rather than
sticking with Ada.

In particular, although I like the assertion stuff in Eiffel, I think
the language has a number of "inelegant" aspects. For example:

   1. exception handlers only at the top level of a routine, with the
      only way to "handle" an exception being by retrying the whole
      routine.

   2. 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.)

   3. Namespace control handled by a separate sublanguage, and no real
      higher level concept of "module" or "subsystem."

   4. An obscure notation like "!!" being used for an important and
      frequent operation (construction).

   5. No way to conveniently "use" another abstraction without
      inheriting from it.

   6. No strong distinctions between integer types used for array indexing.

   7. 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:

   8. No separate interface for an abstraction. You can view a 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.

Hence, 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.

-- 
Mildred Ki'Lya
╭───────── mildred593@online.fr ──────────
│ Jabber, GoogleTalk: <mildred at jabber.fr>
│ Website: <http://ki.lya.online.fr>           GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20100212/d2e72fe2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20100212/d2e72fe2/attachment.pgp>


More information about the Lisaac-devel mailing list