Why Eiffel hasn't met its potential 
Author Message
 Why Eiffel hasn't met its potential

Hi There:

Ive been following the progress of Eiffel over the last few years and I
certainly agree that for many (maybe most) modern programming problems
Eiffel is, on paper, the best choice.

Yet, there are many "practical" problems that the Eiffel vendors have not
yet solved. In my opinion these problems have, so far, relegated Eiffel
to be a niche player. Also in my opinion the advent of Java may further
restrict Eiffels  appeal.

Now, I dont want to pick on ISE, because I do have great respect for
their technology, however their system is the one for which I am most
familiar so I base my comments on their implementation.

Here are the problems I see:

1)  No good GUI builders. I last saw Eiffel Build a few months ago on
Unix. In my opinion it was a technology demonstrator and not a very
useful one. It was very klugy to use, had few components available (e.g.,
lowest common denominator in order to be cross platform), and there was
no way to add more components.
2)  No component openness. Several strategies for creating universal
components are now being thrashed out in the marketplace. Successful use
of component strategies include delphi VCLs and Visual Basic components.
 The growing market for these components will ensure that user needs will
be satisfied (e.g. if there is a need, a vendor will develop).  While the
Eiffel community praises the concept of code reuse, I see no movement
(e.g., no announcements) that Eiffel systems will be able to interface
with some of these growing component communities. Since the pool of
Eiffel developers remain small it is doubtful that such a variety of
goodies will be created Eiffel native, and if they are there will
probably be a large premium due to the smaller Eiffel marketplace.
3)  Poor use of native libraries. Again Eiffel vendors praise reuse but
the actual ability to take advantage of reuse, in the form of standard
libraries, is poor. In the ISE implementation you can only use one
external pre-built library. If you need two pre-built libraries you are
out of luck. Some reuse.

The key here is that reuse and openness is finally becoming a reality,
and Eiffel is NOT poised to take advantage of this. Eiffel needs to be
more open.

While I am not really in a good position to tell the Eiffel vendors how
to best direct their companies, one solution does occur to me. Since the
Java virtual machine is becoming Ubiquitous, and there is an incredible
number of $s being used to develop Java accelerators, I suggest that the
Eiffel vendors abandon C as their target language and use the Java
machine instead. This will allow them to leverage all Java development to
their advantage. Specifically:
1)  This will give them an interpreter available on all platforms which
is maintained by others.
2)  They will reap the benefit of  Java performance improvements (faster
virtual machines, Just In Time Compilers, Java to C translators) at no
cost.
3)  By putting Eiffel wrappers on Java (and other) components they can
let Eiffel users in on the expanding world of cheap non proprietary
components such as GUI elements, Data base connectivity, etc.
4)  Since they no longer have to spend so many $s on optimizations they
can spend more $s on  improving their development environments and
building high performance specialized components such as ISEs
mathematics libraries. (e.g., it doesnt take a great programmer or a
great language to produce a Windows GUI widget but a mathematics
library... thats where the brainpower should be going).
5)  Using the Java VM would instantly make Eiffel Internet friendly.
6)  Using the Java VM would instantly make Eiffel available on all
platforms for which there is a Java machine.
7)  The advent of Java has allowed the programming community to breath a
huge sigh of relief and stop lying about how good C++ is. All sorts of
interesting papers are coming out  on subjects like correctness and
robustness. It seems that The Eiffel community should be able to take
advantage of this "new" view on how to program (For those of you who have
not seen it, in some ways Java could be regarded as "Eiffel Lite with a C
syntax."

I would like to hear others opinions on these subjects.  Feedback from
the Eiffel vendors would be most appreciated.

Thank you,

Jeffrey W. Stulin



Fri, 25 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential

Quote:

> =
> Java virtual machine is becoming Ubiquitous, and there is an incredible
> number of $=92s being used to develop Java accelerators, I suggest that t=
he
> Eiffel vendors abandon C as their target language and use the Java
> machine instead. This will allow them to leverage all Java development to=
> their advantage. Specifically:
> 1)  This will give them an interpreter available on all platforms which
> is maintained by others.
> 2)  They will reap the benefit of  Java performance improvements (faster
> virtual machines, Just In Time Compilers, Java to C translators) at no
> cost.
> 3)  By putting Eiffel wrappers on Java (and other) components they can
> let Eiffel users in on the expanding world of cheap non proprietary
> components such as GUI elements, Data base connectivity, etc.
> 4)  Since they no longer have to spend so many $=92s on optimizations the=
y
> can spend more $=92s on  improving their development environments and
> building high performance specialized components such as ISE=92s
> mathematics libraries. (e.g., it doesn=92t take a great programmer or a
> great language to produce a Windows GUI widget but a mathematics
> library... that=92s where the brainpower should be going).
> 5)  Using the Java VM would instantly make Eiffel Internet friendly.
> 6)  Using the Java VM would instantly make Eiffel available on all
> platforms for which there is a Java machine.

=3D=3D=3D=3D=3D=3D=3D=3D
That's a pretty interesting idea. Certainly other vendors have started =

putting Java back-ends on their language products. Intermetrics, for =

example, is beta testing a Java backend for their Ada compiler.

My initial reaction was that Java lacks something vital supported by =

Eiffel, Ada, and C++: generics (templates in C++). Intermetric's =

AdaJava doesn't support generics yet. The immediately following thought =

is that Eiffel front-ends to a C compiler (which has no advanced =

features worth speaking of), so this may not be a problem after all. =

Another barrier to overcome would be performance. Eiffel code is =

noticeably slower than equivalent C/C++ code; adding the overhead of =

Java's VM could be a killer. OTOH, toy applications that these are, =

perhaps speed is not the important issue.

Java has the disadvantage that it offers no real compelling advantage in =

general application programming. Why use Eiffel as its front-end, then? =

Java's distribution model (OK, so it has one :) is clearly its most =

compelling asset. The paradox is that the tools most needed for general =

application programming -- eg.: database access, GUI design -- are =

useless in this distribution model. Do you really want to export your =

database, not just an interface to it?

Quote:
> 7)  The advent of Java has allowed the programming community to breath a
> huge sigh of relief and stop lying about how good C++ is.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Java will never be the C++ killer some are hyping/hoping it to be. I =

wish they'd stop telling lies about how bad C++ is. Very few evangelists =

knew or cared what they were speaking up against.

Mike.



Fri, 25 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential

| Another barrier to overcome would be performance. Eiffel code is
| noticeably slower than equivalent C/C++ code; adding the overhead of

This is not my experience.  Eiffel programs compiled with the
TowerEiffel optimizer routinely benchmark roughly the same as
equivalent C++ programs (usually within 10-15% -- sometimes slower,
sometimes faster).  Customers have reported doing experiments where a
design is coded in idiomatic Eiffel and C++.  Much to the project
leaders' surprise, the Eiffel versions often actually out-perform the
C++.  I can't supply details on any particular tests, but these
results are not particularly suprising to me. C++ is full of hidden
inefficiencies (constructor overhead, implicit copy constructors,
etc.)  And its lack of garbage collection encourages a "make a copy of
everything" style of programming which is inherently slow.  C++
programmers seem to _think_ that C++ is fast (it looks like C, one has
to manually deallocate memory, it feels like you're programming "close
to the metal", therefore it must be fast, right?), but is it really?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
C++: One million lemmings can't be wrong.


Tower Technology        WWW:      http://www.twr.com/



Sat, 26 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential

Quote:
> [Summary]
> Eiffel isn't realizing its market potential
> because there is not enough manpower (and money)
> available for the development of GUI builders and libraries.
> Conclusion:
> Eiffel compilers should be retargeted to the Java VM
> to allow reusing the improvements other apply to the JVM.

Just what I thought (though I haven't been exposed to EiffelBuild  
yet, so I can't comment on GUI builder quality).

The Eiffel compiler vendors are undermanned and underpowered to  
push a new language into the market. (BTW Eiffel isn't even  
really new either...) I feel they're trying to let the advantages  
of Eiffel speak for themselves.
This doesn't suffice.
I don't know why Java is such a success, but even if Sun dropped  
the support today (or, say, in a few months), enough people would  
have committed to Java to make it go on until hell freezes over  
(or fortran dies, whichever comes first). I guess it is the  
combination of a lot of carefully selected factors that make Java  
irresistible:
- a company that's there to stay
- an acceptable language design
- a free compiler, linker, etc.
- classes that allow immediate building flashy mini-progs
- the prospect of true portability
- built-in Internet access
- a promise to address security issues
All people that have a say in the success of a programming  
language (students, professors, hackers, and managers) all find  
good points in the language. It isn't best in any respect, but it  
performs adequately on any and doesn't show serious weaknesses.

Now look at Eiffel - no universally accepted set of classes (not  
for GUIs, not even container classes), no immediate way of  
building primitive applications that look well (commonly called  
Rapid Prototyping - absolutely essential if you want to impress  
manager types), no true portability, no standard Internet access.

Many of these issues could be easily resolved, but I don't see  
the Eiffel vendors converge on standard libraries. This means  
I'll have to adapt lots of my program's base whenever I want to  
change from one vendor to the next.
And this is a problem that won't go away just by porting to the  
JVM; it actually requires an easy (!!!) integration of outside  
routines. If this compromises system security, put a warning flag  
on it, but let the market decide wether that is good or evil.  
Anybody should be able to determine his own level of insecurity,  
and if inclusion of VBXs compromises portability and class  
design, so be it. Maybe that anybody doesn't need portability.  
And probably he wouldn't be able to build a good class structure  
anyway.

Fact is, 90% of business application programming is a set of  
forms to input data, and a set of programs to retrieve that data;  
plus a bit of code to consolidate data.
These can be formidable tasks in themselves, but most time is  
spent (wasted) in programming screen I/O. As long as Visual Basic  
allows you to whip up an input form faster than EiffelBuild,  
Visual Basic will win.

-Joachim

--
Im speaking for myself here.



Sat, 26 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential
Very well, then; but please don't cross-post this to c.l.c++. For me,
the Eiffel side of this discussion is much more relevant than that from
the knee-jerk defenders of <that other language>.

Quote:


> | Another barrier to overcome would be performance. Eiffel code is
> | noticeably slower than equivalent C/C++ code; adding the overhead of

> This is not my experience.  Eiffel programs compiled with the
> TowerEiffel optimizer routinely benchmark roughly the same as

=======
Eiffel/S only, and only on somewhat trivial "test-this-or-that"
programs. If I were to time my (what does ISE call it? thawed?)
unoptimized Free ISE Eiffel code, the discrepancy would probably be
higher.

Quote:
> equivalent C++ programs (usually within 10-15% -- sometimes slower,
> sometimes faster).  Customers have reported doing experiments where a
> design is coded in idiomatic Eiffel and C++.  Much to the project
> leaders' surprise, the Eiffel versions often actually out-perform the
> C++.  I can't supply details on any particular tests, but these
> results are not particularly suprising to me.

=========
Alas. Hard facts -- numbers, plus relevant details of implementation and
environment -- would be useful.

Quote:
> C++ is full of hidden
> inefficiencies (constructor overhead, implicit copy constructors,
> etc.)

=========
Eiffel has creation methods, so I expect this comparison to be less than
meaningful. That you call them explicitly, without name overloading, is
hardly relevant to runtime performance. As to the nuts and bolts of
programming, some C++ programmers are less aware than others of when
temporaries might be constructed. This, leads us to object ref's,
discussed below, and awareness, also discussed below.

In terms of hidden costs, some programmers I worked with (and I
similarly at one point) split hairs to avoid the cost of virtual
functions. While I don't applaud their attention to detail, this brings
to light certain costs involved in indirection. I believe the default
mode (only mode?) for Eiffel methods requires indirection. This might
actually be a plus for usability (but not performance) when the compiler
can recognize statically when indirection is not required; I expect C++
programmers will be more consciously aware of this possible cost than
Eiffel programmers.

Is this enough to make a difference? I would guess yes; the magnitude
varies from small to miniscule perhaps, on the side of C++.

Quote:
> And its lack of garbage collection encourages a "make a copy of
> everything" style of programming which is inherently slow.

=========
Hardly. Very usually, GC is fully emulated with a very thin wrapper
around {*filter*} pointers. This equates to the same functionality and
probably equivalent overhead of Eiffel object ref's. When you consider
that many objects need not be dynamically allocated, the savings add up
to some measurable sum. As for copying objects, even the more primitive
compilers optimize away the need for a copy; the returned object is
constructed in the caller's memory space.

Like you, I have no statistics or citations to back up the following. My
gut feel, though, is that roughly half the object use in C++ are local
objects. These equate to Eiffel expanded locals, and do not require
dynamic allocation. This is the default mode for locals in C++; memory
is not dynamically allocated, nothing is garbage collected. The default
mode for Eiffel is object ref's, requiring dyn. allocation and
subsequent garbage collection. I suspect at least a moderately lower use
of expanded locals than in C++, simply because GC and the default mode
"obviates" the need.

Quote:
> C++
> programmers seem to _think_ that C++ is fast (it looks like C, one has
> to manually deallocate memory, it feels like you're programming "close
> to the metal", therefore it must be fast, right?), but is it really?

=======
Was this rhetorical, or are you asking *me* for citations?

In a larger sense, Eiffel, Java, VB, and their ilk lower the entrance
requirements relative to C++. The syntactical elements of programming in
these languages reputedly have a gentler learning curve than C++. Thus,
a programmer with relatively low experience is able to produce average
work somewhat more quickly. To be similarly rhetorical, is this
necessarily a *good* thing?

The system knowledge -- that larger body of understanding what a program
is doing -- remains as large and foreboding as it ever was. Some
implementors manage to climb the curve eventually, regardless of the
language they use. When they reach that point, being able to program
"close to the metal", as it were, might become meaningful. The key
phrase there was "being able to", as in "empowered", unlike "required
to", and as distinctly opposed to "prevented from." In context of
understanding the system behind the program, is it necessarily a good
thing to hide the inner workings? Wouldn't this slow the larger learning
process?

Being aware of what a line of code does goes far beyond the impact of a
local inefficiency. There really is no shortcut to understanding what
the system is doing, and this remains largely language independent.
Programming for performance is a parallel skill to understanding
abstractions. They are not contradictory, and at least one language
allows me to express both very efficiently and eloquently. Can you say
the same about <your favorite programming language>?

I believe that Eiffel and C++ are more alike than they are different. A
poor understanding of abstractions leads to bad designs in both. A poor
undestanding of performance dynamics leads to slow systems in both.
There are rare opportunities where the flexibility of C++ will make a
difference in the outcome. More importantly, though, C++ obscures less
of the internal workings, allowing (not forcing) a deeper understanding
of certain interactions.

There comes a point in building any system when matters become less one
of design abstractions, and more one of implementation pragmatics.
Eiffel only gets you 90% of the way there in this sense. Unfortunately,
that last 10% only helps those systems that are properly designed in the
first place. It's not a matter of 10% more effort at the end; it's a
matter of applying pragmatics throughout the implementation, without
sacrificing abstraction. This is where experience and awareness are
necessary. In other words, this is language independent, but again, for
the reasons given above, the advantage falls ever so slightly on the
side of C++.

Quote:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> C++: One million lemmings can't be wrong.

:) I eat less red meat than I used to. Do you? Why or why not?

Mike.



Sun, 27 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential
Steve,

:=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
:C++: One million lemmings can't be wrong.

Your signature comments are priceless!

Regards,
Don.



Sun, 27 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential
There is little to add to what Steve Tynor posted about the myth
that C++ is faster than Eiffel. ISE has published several benchmarks
showing ISE Eiffel to be as fast or faster as C, in particular on
numerically-intensive array computations - the kind for which
performance has traditionally been of the utmost concern.

We will be reactualizing these benchmarks for the latest releases
of our compilier and including them in our Web pages. This myth
should be killed once and for all.

--
Bertrand Meyer, ISE Inc., Santa Barbara (California)

Web home page: http://www.eiffel.com

        (The "lapel pin" [++] indicates adherence to the
        SELF-DISCIPLINE program for better Usenet discussions.
        See http://www.eiffel.com/discipline.)



Mon, 28 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential

Quote:


> >> C++ is full of hidden
> >> inefficiencies (constructor overhead, implicit copy constructors,
> >> etc.)

> >=========
> >Eiffel has creation methods, so I expect this comparison to be less than
> >meaningful. That you call them explicitly, without name overloading, is
> >hardly relevant to runtime performance.

> Oh yes it is.  The point is that implicit copy constructors are one of the
> main tools needed in C++ to create abstract data types: its how tell the
> language how to make a copy of your object when a bitwise copy won't do.  But
> then every time you call a function or make an assignment with that type,
> the copy constructor gets called.  And since C++ lacks garbage collection,
> you keep having to make copies so that every module has exactly one copy
> to deallocate when its finished with it.  In Eiffel you usually pass a
> reference around.  Much faster.

While I agree with much of what you say Paul, I couldn't let you get away
with this one. C++ supports references, either as pointers or as, well,
references. In fact, the main difference between C++ and Eiffel in this
regard is that Eiffel doesn't allow you to construct a reference to an
expanded type, and C++ does.

[...]

Quote:
> >> And its lack of garbage collection encourages a "make a copy of
> >> everything" style of programming which is inherently slow.

> >=========
> >Hardly. Very usually, GC is fully emulated with a very thin wrapper
> >around {*filter*} pointers. This equates to the same functionality and
> >probably equivalent overhead of Eiffel object ref's.

> Here is a man who does not know about garbage collection.

> GC is not implemented with a "very thin wrapper" around pointers.  It can
> be done in C++, but only at considerable overhead.  In Eiffel, the GC can
> rely on co-operation from the language.  Not in C++.  If "smart pointer"
> overloads are used then their operations cannot be optimised (e.g setting
> a "dirty" flag on a pointer only once instead of every time it is used).

One point to note about garbage collection is the uncertainty it
introduces about when objects get deleted and what happens at that
time. The more event driven programming I do (both GUI and interrupt
driven embedded systems) the more I am beginning to appreciate the
benefits of being able to create an object and execute its constructor
routine at the start of a callback then invoke its destructor and
delete it at the end. Possibly the classic example of this is a GUI
callback which requires an 'hourglass cursor' during execution. In C++
I can write (or reuse of course) an hourglass cursor class whose
constructor saves the old cursor and replaces it with an hourglass,
and whose destructor reinstates the old cursor. Placing a local
declaration of an object of this class in the callback automatically
guarantees the functionality I want. With GC I would need
(a) a means of associating a finalisation function with the object
(b) a way to guarantee that the object got deleted at the end of the
callback.
OK, the above example uses a side-effect with a capital
S (bold-italic :-) but I see nothing wrong in a paradigm where the
environment in which a routine operates is determined by the
declarations at the head of the routine.

[...]

Quote:
> >Being aware of what a line of code does goes far beyond the impact of a
> >local inefficiency. There really is no shortcut to understanding what
> >the system is doing,

> Very true.  Anyone would think from this that you were in favour of Eiffel.

>  and this remains largely language independent.

> Wrong.  Eiffel is *much* easier to understand.  To see why, I suggest
> a good read of "Object-Oriented Software Construction" by Bertrand Meyer.

Yes, but you have to read the fine print, just as you do (but in a
different place) in any other language. For example, in my Eiffel
compiler, Eiffel/S, and also, as far as I remember in the ISE Free
Eiffel, all the interfaces to the ARRAY class are implemented as C
function calls. Just imagine the {*filter*} shocks that would give to a
programmer doing finite element analysis when he realises that
multiplying an element in an ARRAY[FLOAT] by 0.5 takes two function
calls (one to get it, one to put it back) !!!

Quote:
> >Programming for performance is a parallel skill to understanding
> >abstractions. They are not contradictory, and at least one language
> >allows me to express both very efficiently and eloquently. Can you say
> >the same about <your favorite programming language>?

> In my case, Eiffel.  Yes I can.

But, of course, it does depend on the application domain
Quote:

> Paul.

Bill Williams

--
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!


Tel: +44 1245 242016
Fax: +44 1245 242003



Mon, 28 Sep 1998 03:00:00 GMT  
 Why Eiffel hasn't met its potential
Hi, Eiffelists,

 >
 > There is little to add to what Steve Tynor posted about the myth
 > that C++ is faster than Eiffel. ISE has published several benchmarks
 > showing ISE Eiffel to be as fast or faster as C, in particular on
 > numerically-intensive array computations - the kind for which
 > performance has traditionally been of the utmost concern.

I'm reasonably familiar with the language specification of Eiffel but
do not have experience in it.

I'm just curious about how typical Eiffel compilers implement
parametric classes.  If performance of Eiffel is close to that of
C/C++, I imagine Eiffel compilers generate different versions of
methods for different instantiation of class parameters.

What I know about this topic in general is what C++ compilers (g++,
more precisely) do and works in implementation of parametric
polymorphism (mainly in the context of ML).  

If I'm correct, what g++ compiler does is whenever the compiler finds
the current compilation unit uses a method of a parametric class, the
compiler emits the appropriate version of the method IF IT IS VISIBLE
IN THE CURRENT COMPILATION PROCESS.

As a consequence, you must be very careful for avoiding
"undefined/duplicated symbol" errors at link time.  Besides, it seems
difficult for library vendors to ship the binary code for template
libraries of C++ (majority must be written in header files).  On the
other hand, this implementation ensures that performance is very close
to what would be achieved if there were no parametric class
facilities.

There are also many works in implementation of polymorphism in ML.
I'm not quite sure the state-of-the-art of this line of work but as
far as I know most of them currently suffer from either bad runtime
performance (especially on floating-point intensive benchmarks),
complexity of the compiler, or compile time performance.

any info/pointer is appreciated.
--
                Kenjiro Taura
                Yonezawa Laboratory, Department of Information Science
                Tokyo University



Fri, 02 Oct 1998 03:00:00 GMT  
 
 [ 53 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. why Haskell hasn't replaced CL yet?

2. October's Colorado Eiffel User's Group Meeting

3. Minutes of the April meeting of the Colorado Eiffel User's Group

4. Minutes of the March 27 meeting of the Colorado Eiffel User's Group

5. March meeting of the Colorado Eiffel User's Group

6. February meeting of the Colorado Eiffel User's Group

7. Minutes of the October meeting of the Colorado Eiffel User's Group

8. Minutes from the September 2002 Meeting of the Colorado Eiffel User's Group

9. smalltalk hasn't made it big

10. Who hasn't sued ben & jerry

11. Ada as a first language - Hasn't got it yet

12. Who hasn't heard this yet?

 

 
Powered by phpBB® Forum Software