Re: [GD-General] Eiffel

[Kent Q. <ken...@co...>]

Back to the original question. I've been reading the critique Brian
posted:

This critique of C++/Java/Eiffel and others is dated from 1996, so it's
a bit old at this point. Some of the things he criticizes have been
changed in various ways in all of the languages. The paper could
definitely use a fourth revision. (It appears he wrote a book in 1999 by
starting from the paper, so you probably have to buy the book to get an
update.)

My general first take on Eiffel is that it seems awfully wordy and
cumbersome. I understand and generally agree with the concept of writing
more when coding to save trouble later; I use long variable names for
just that reason. But the language has Bertrand Meyer's Pascalish bias
all over it, and having been frustrated by coding in Pascal for a number
of years, I developed a strong allergy to that style. It's a sort of
leather and handcuffs kind of style.

I also found this document:

http://www.elj.com/eiffel/cpp/cpp-report-pd/

And in there, I found these items among a list of things that piss off
C++ programmers -- and they're about the kiss of death as far as my use
of Eiffel is concerned:

-------
No overloading. Eiffel does not allow a feature to be overloaded on the
basis of the types of its arguments. This sometimes leads to rather
artificial manual overloading, as found in the standard IO routines
(put_string, put_character, put_integer). 

However, overloading was not omitted by accident. Not only was it
considered by Eiffel's designer to be of questionable value and not
without costs, but it also would unduly complicate the inheritance
mechanism, which relies on unique names to identify each feature of a
class. Again, it comes down to favoring readability over writeability
and eliminating ambiguity. 

No nested classes. A class cannot be declared within the scope of
another class, nor within a routine. This is not an oversight, but a
deliberate decision. Classes are meant to be reusable modules, and if
one class is written inside another, then it has such a strong
dependency with the enclosing class that it cannot possibly be reused
independently. 

In C++, nested classes are merely a scope issue, rather than a semantic
issue. Thus, if C++-style nested classes are desired, they can be
achieved merely by prepending the enclosing class' name to that of the
nested class, and access to the "enclosing" class' features can be
granted through selective export. 
----------

I understand the logic behind these decisions -- but to me, it feels
like the arguments in favor of them are particularly weak, and evidence
of design by someone who hasn't done a lot of large scale programming. 

Removing overloading removes ambiguity, yes, but it actually increases
complexity by forcing the programmer to maintain a mental list of all
the different ways to do the same task with different objects. I'd
rather have the compiler deal with ambiguity and "undue complications"
than force me to deal with it. I spent WAAAAAAY too much time
duplicating code to handle different types in the bad old days of
Pascal. I don't want to go there again.

Regarding nested classes, there are uses for classes in implementation
as well as design. Not every class needs to be public or reusable. In
fact, one of the things that I love about Java and wish that C++ had was
anonymous classes. They provide the only way to deal with the concept of
functors in generic algorithms where the functor is defined at the same
point as the algorithm is used. In C++ you can put it nearby. In Java
you can stick an anonymous class right inline. It's a powerful, useful,
and very general mechanism, similar to a lambda notation. 

Now if Eiffel supports a lambda notation (I haven't found it) and I've
missed the fact, I'll take this one back. 

I'd really like to find a language that makes more sense in a production
environment than C++ or Java. 

C: "You can do whatever you want."
C++: "You can do whatever you want, if you can figure out how."
Java: "You can do whatever you want that's safe."
Perl: "You can do whatever you want any way you want, and preferably not
the same way twice."
Pascal: "You can't do anything."
Eiffel: "You can do whatever we want."
Python: "Whatever."

Any counterarguments?

	Kent



-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________