Re: The disturbing myth of Eiffel portability

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "paul.johnson" == Paul Johnson <paul.johnson@gecm.com> writes:

paul.johnson> In article <vwj20dodc99.fsf@osfb.aber.ac.uk>,
paul.johnson> pcg@aber.ac.uk says...

pcg> [ ... ] In this respect Eiffel is rather less attractive; user
pcg> defined Eiffel datatypes are not quite on a par with builtin ones
pcg> either as to syntax (which IMNHO is not important) or as to
pcg> performance (which matters for very fine granularity datatypes).

paul.johnson> Syntax first: I think you will find that the built-in
paul.johnson> Eiffel data types are on a par with the user-defined ones:
paul.johnson> unlike C++ things like integer and array are defined as
paul.johnson> classes.

Well, only in Eiffel 3, which is a rather different language from Eiffel
(despite backwards similarity); and even in Eiffel 3, they are a bit
more special than user defined types.

  BTW, it's clear that different people mean different things with
  ``Eiffel''; the various versions of the language are rather
  different. The same applies to ``Ada'', ``C'', ``FORTRAN'' and also to
  ``C++'', where one never really knows _which_ version of the language
  is being discussed, for while for example for Ada and C and FORTRAN
  there is a customary indication of version (Ada 83 and Ada 95, C and
  ANSI C, FORTRAN 66, FORTRAN 77, ...) I have very rarely seen any usage
  of the C++ 1.0, C++ 2.x, C++ 3.x or C++ draft ISO @ [date] labels. In
  part this is because C++ implementations often implement bits from
  several versions...

What has most impressed me in the changes between Eiffel and Eiffel 3 is
the obvious change of many important design decisions, and the giving of
much greater importance to aspects that have always ben central to the
design of C++ (there are many examples: from 'expanded' to 'bit N').

If Eiffel had been designed from the start as a more C/C++ like
language, the ugliness of certain aspects of Eiffel 3 could have been
avoided...

paul.Johnson> Efficiency: see the thread about benchmarks.  Where
paul.johnson> exactly do you think that user defined data types lose
paul.johnson> performance?

Memory management, for like in SIMULA, they ``must'' be heap allocated,
and accessed indirectly via pointers/references (and without something
like the 'WITH' construct of Pascal or block prefixing as in SIMULA).

In Eiffel 3 they _need not_ be heap allocated; but then there are other
aspects that more or less mandate the existence of a system builder,
which is indeed duly provided (certain overheads can only be avoided if
a program-wide optimization is done), but which causes its own
difficulties (convenience more than performance).

pcg> It is rather significant IMNHO that Eiffel 3 has now expanded
pcg> datatypes, which however small a detail, allows for _considerable_
pcg> improvements in performance, in particular asd to garbage
pcg> collection.

paul.johnson> More importantly, it has allowed the builtin data types to
paul.johnson> become part of the class hierarchy.

Well, this is elegant indeed (except for abominations like 'NONE', which
was justly criticized in the discussion of Eiffel in OOSC); but I think
that the problem with having all non-primitive values accessed by
reference and in the heap was a far bigger problem as to the
practicality of using Eiffel than the inability to have basic types part
of the class hierarchy.