Xref: utzoo comp.lang.eiffel:228 comp.lang.c++:3548
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!gatech!emory!dtscp1!tridom!lam
From: lam@tridom.uucp (Larry Morris)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Summary: A language user's response
Message-ID: <124@tridom.uucp>
Date: 5 Jun 89 22:57:15 GMT
References: <2689@ssc-vax.UUCP> <150@eiffel.UUCP>
Organization: Tridom Corporation, Atlanta
Lines: 119

In article <150@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes:
> 
>     Finally I do not think that in the long term Eiffel is really
> ``competing'' with C++. They have almost nothing in common in their aim
> and spirit, as explained in the final section of this message.
> In my undoubtedly biased view, the real competitor to Eiffel is Ada.
> (``Competitor'' for me is a positive word. When you acknowledge
> a design as a competitor to yours, it implies respect.)
> Ada, as already mentioned, is not truly object-oriented, but its official
> charter (reliability, reusability, professional high-quality software
> development etc.) is very similar, on paper at least, to that of Eiffel.
> 
I find this view surprising, even though I'm willing to concede that Eiffel
is radically different from C++, and more modern in its design.  Ada, from
what I've seen, is used more by mandate than choice [not that it's a 
particularly "bad" language, but I'd be willing to bet that nearly all 
new engineering users of Ada have a DoD standard on their desks].
Setting up Ada as the "competition" seems like a strawman to me.
As for the "charter" of C++, was it intended for unreliable, one-time,
amateur, poor-quality software development?  I doubt that Stroustrup's
intent was significantly different than yours. I see C++, Objective-C and 
Smalltalk as Eiffel's most obvious competitors for the engineering
marketplace, as much for political as design considerations. Ada is likely
to remain comfortably entrenched in its own well-protected market.

> can talk about the very idea of reusable software components without
> assertions...
> maintained by the amplifier). Yet of widely available programming
> languages, only Eiffel has these notions.
Assertion checkers, of course, have been used for years as tools outside
the scope of the language, as libraries, or extracted by tools from
code comments. Placing assertions within classes as part of the language
is, I must agree, a very powerful feature. But Eiffel's design philosophy
calls on programmers to define their classes with assertions in addition
to coding their implementation; something most programmers aren't used to
doing and may view as an onerous task. Since assertion checking isn't any
better than the assertions dreamed up by the programmer, I'm skeptical of
using it to "replace" unit testing.
> 
>     Eiffel has exception handling. Its exception mechanism is original and
> I believe it is one of our major contributions, based on the theory of
> ``Programming by Contract''. As far as I know, there is
> no exception mechanism in C++. I believe that one cannot write
> serious software without having a way to recover cleanly from unexpected
> cases.
> 
I agree 100% with this, and I view it as the single biggest selling point
of Eiffel over C++.
> 
>     In C++ as in Ada a routine may be declared as ``in-line'', meaning
> that calls will be expanded in-line to gain performance. No such mechanism
> is available in Eiffel....
>  The optimizer will automatically
> expand certain routines in-line based on systematic criteria beyond
> programmer control...
> 
I'm a bit skeptical about this approach. In data communications software
(or other types of real-time software) it's frequently necessary to optimize
certain methods heavily. I'd like some choice over this without having to
resort to an assembly language or C call-out. How many times must I reference
the method before your optimizer decides to inline it? How many lines may I
add to the method before your approach changes? By adding a line, will I
speed things up or slow them down?
>     
>     To write serious object-oriented software, which at run time will
> inevitably generate many objects, some of which may become useless,
> one needs a good garbage collector. This is the case in Eiffel
> (which uses an incremental, parallel scheme so as not to impair performance).
> As far as I know, C++ systems do not support garbage collection,
> which would be extremely difficult if not impossible to implement
> because of the presence of C types and mechanisms.
Obviously, one does not need a good garbage collector if one cleans up 
after oneself. Having been burned before by garbage collection, I remain
wary of claims of efficiency. With C++, I control allocation and deallocation
of memory resources explicitly, so I know their performance impact. With
Eiffel, do I just trust that you won't collect garbage at an inopportune
time, like halfway through emitting a frame?

> Compatibility with C means that in C++ you still have pointers,
> type casts, pointer arithmetic, function pointers, malloc, free, bizarre
> operator precedence (the famous asterisk/parenthesis bugs),
> weak type checking and so on.
>     In Eiffel, the choice has been made. None of these low-level features
> are present (as John Sarkela pointed out in a previous message); needless
> to say, they are not missed.
In analyzing incoming data frames, we freqently encounter the problem of
extracting or adding variable-length headers, at various positions in a
byte array. It's most convenient (and efficient) to be able to adjust a byte
pointer, then reinterpret the pointer as a struct pointer. This may not be
"textbook" programming style, but life isn't filled with textbook problems 
either. The pragmatism of C in these situations is one reason I prefer it to
Pascal these days, and why I endure all of C's warts.  Yes, I want many of 
the benefits of Eiffel...but when I need just to get the job done, will I
be calling my old C routines because your choices didn't fit?
>     Learning a new language such as Eiffel is nothing for a
> competent programmer. For Eiffel, which is small and simple,
> the learning process typically lasts a few days at most.
Natch! I learned C in a few days, few being a relative term. Becoming fully
versed and competent took a "few" more, and I might still have a couple days
to go.
You're probably right about being easier to learn than C++, though, not
having the forward interference from C to contend with.

As someone involved in the selection of an OOP language, I have to say that
the decision between C++ and Eiffel isn't a trivial one. Many of the factors
are political, since C++ has a large and "grass-roots" support base, while
Eiffel is relatively new to the scene, and more academic in its "feel." I
think the decision will be influenced strongly by support tools, since
successful OOP programming, IMHO, depends on making classes available to
a team in an accessible and controllable manner. Eiffel has a solid, but
largely proprietary, environment set; C++ seems bogged down in this area,
but with many vendors interested.
I hope both ISE and AT&T feel some healthy competition between their products,
since this will encourage more tool development. These days a language can't
be considered realistically outside of its tool environment; this goes double
for an OOP language.

Larry Morris, Tridom Corporation
...!emory!tridom!lam