[comp.lang.eiffel] EC++, C++ and Eiffel

dmg@ssc-vax.UUCP (David Geary) (10/28/89)

In <208@eiffel.UUCP>, Bertrand Meyer writes:

-     If imitation is flattery, I certainly have reason to be honored
- by the recent ``EC++'' posting. With the exception of the garbage
- collection strategy (for which I believe our approach to be superior),
- everything it adds to C++ is directly lifted from Eiffel.
- The promised ``future developments'' have been present in Eiffel for years.

  I am currently reading Dr. Meyer's book - Object Oriented Software
Construction (an excellent reference for OOP - I highly recommend that anyone
seriously interested in writing OO code read this book).  After reading
the "EC++" posting, I thought that EC++ stood for:

Eiffel-ized C++   ;-)

  Obviously those involved in creating EC++ were greatly influenced by
Dr. Meyer's work.

-     If we ever needed a confirmation that we have been doing the right
- thing all along (rather than following whims of fashion), this is it.

  Agreed.

-     Reinventing the wheel (especially if done with some of the proper
- acknowledgments, as here) is permitted. In the meantime, of course,
- we are working on the next steps. Good luck anyway.

  Yes, I believe that as C++ matures, many of the features of Eiffel
will find it's way into C++.

-     I am afraid, however, that the path followed by the posting -
- yet another set of semi-compatible extensions to an obsolete technology -
- holds little promise. 

  Ok - two things here:

1)  EC++ is a set of semi-compatible extensions:

  This is true, and, in fact my first thought when I read the EC++ posting
was - "yeah, this is good stuff, but who is going to use it?".  There is 
no way that I could get my boss to go for something like EC++ - no matter
how many wonderful things it adds to C++, it is non-standard.  Who
"supports" EC++?  How can I get EC++ on a Sun, Apollo, and IBM RT?
After I leave the company, how many programmers will be able to maintain
my EC++ code?  And this is only the tip of the iceberg as far as problems
associated with using a non-standard extension to any language.

  However, issues raised in the last paragraph concerning the usage
of EC++, can also be raised concerning the usage of *Eiffel*.

2)  obsolete technology:

  I assume here that the obsolete technology is C.  Yes, it's true that
C has many warts, and is not suited for Object-Oriented programming.
However, much, much code has been written in C, and an object-oriented
extension to C (that is close to being a superset of C) is, IMHO
a good thing.

-     This is not an inappropriate place to repeat (for those readers who
- prefer originals to imitations) that anyone is free and welcome
- to produce an implementation of Eiffel - compiler, interpreter, ... -
- as well as libraries, tools and the like. The name is a trademark and
- must be acknowledged, but that's all.
 
-    It is so much more fun to do the real thing.

  If I were programming in an ideal world, where my only concern was
to use the "best" language available, no doubt I would choose Eiffel.

  However, I am programming in the real world, for a real paycheck,
and 9 times out of 10, I'm going to go with C++ instead of Eiffel.
There are several reasons:

1)  My boss has heard of C++, and is comfortable with my using it.
    He has never heard of Eiffel.

2)  C is closely tied to Unix - rapidly becoming *the* operating
    system of choice.  C++ will no doubt follow suit.  Any workstation
    that runs Unix most likely already has a C compiler, and, in
    the future, certainly it will be a C++ compiler.  Eiffel is
    only on machines that *I* load it on to. (and in some cases only
    on machines that *I* port it to).

3)  C++ comes from AT&T.  This is a biggie.  Look at the IBM PC.  It's
    unarguably a technological dinasour which lags behind most
    other PC's.  However, what computer is everyone writing software
    for?  IBM.  What computer does Joe Average get when it comes
    time to "learn what computers are all about"?  IBM.  Why?
    Because it's IBM.

4)  Many companies are starting to produce compilers/translators for
    C++.  I can get C++ for Suns, Apollos, IBM PC, IBM RT, Amiga,
    and on and on.  Zortech, Lattice, Oregon Software, Glockenspiel,
    Sun, Apollo - all of these guys are pumping out C++.  

    What companies are writing Eiffel compilers?  How many different
    platforms can I get Eiffel for?

5)  After writing 20,000 lines of the most beautiful, most reusable,
    most easily changeable code in the world, what will my boss
    do when I leave the company?  Who is going to maintain my code?
    If it is written in C - no problem.  If it is written in C++ -
    no problem (well, maybe a little problem at present, but not
    for long).  If it is written in Eiffel?

- Although few will listen, as few have listened in
- the past, I will once again repeat Hoare's and Wirth's admonition: you don't
- build programming languages by adding features ad libitum.
- Hoare was reacting to the orgies of the sixties, but the
- present circumstances are not much better. Like any other good engineering

  Agreed.  Programming languages which grow through additions of features
'ad libitum' (whatever that means ;-) are probably not worth much.  However,
this is not the case with C++.  I perceive C++ as growing in a very sane
manner, with changes coming about through careful consideration of user
feedback.

  Eiffel IMHO, is the "best" language available today.  However, it is
not available *enough*, is not being supported by a multitude of companies,
and hardware manufacturers, and therefore will never become as popular
or used as much as C++.

  C++ is maturing.  Many users of C++ are discovering that C++ should
have features that are found in Eiffel (multiple inheritance, and 
genericity, and, of course, all that is found in EC++).  Users of C++
are discovering that these features are necessary to produce robust,
reusable code.  Dr. Meyer should be flattered; I believe that C++
will incorporate more and more of the features of Eiffel as it
matures further.

  However, Eiffel, for many reasons (some of which are stated above)
is not being used as much as it should.  I for one, agree with the
principles Dr. Meyer has laid out in OOSC, but, as a real person
in the real world, I will continue to use C++.

		  --- David Geary ---
		  (A reformed C programmer)
-- 
~~~~~~~~  David Geary, Boeing Aerospace, Seattle  ~~~~~~~~
~ We got lucky this year, summer fell on Friday and Sat. ~
~ and it only rained on Friday ;-(                       ~

dmn@stiatl.UUCP (Michael Nowacki) (11/17/89)

In article <2942@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes:
>
>  This is true, and, in fact my first thought when I read the EC++ posting
>was - "yeah, this is good stuff, but who is going to use it?".  There is 
>no way that I could get my boss to go for something like EC++  ...
>
>  I assume here that the obsolete technology is C.  Yes, it's true that
>C has many warts, and is not suited for Object-Oriented programming.
>However, much, much code has been written in C, and an object-oriented
>extension to C (that is close to being a superset of C) is, IMHO
>a good thing.

this is the reasoning that has extended the life(sic) of COBOL so long. as for
extensions, have you ever written any embedded-SQL code? it probably seemed as
much of a descretionary compromise as c++ does now, at first. 15 years from now
you'll probably be defending the continued use of the as-yet-to-be-invented
Zorch-plus(tm) system, because everybody else uses it, even though the newer
hcroZ-minus is demonstratively better.
managers aren't supposed to be creative, that's why they're managers. you can't
_manage_ an unknown entity, so they will tend to oppose radical innovation. 
they don't need you to be a devil's advocate. the principle that you pay now 
and reap the benefits later (or scrounge now and pay more later) is neither
new nor obscure in this industry. and if the technicians aren't going to keep
making this point, who will?
-- 
Michael Nowacki               gatech!stiatl!dmn
Sales Technologies, Inc             |\  /|
3399 Peachtree Rd, NE               | \/ |
Atlanta, GA  (404) 841-4000        _|ike |_