Eiffel disadvantages
LORENA GARCIA DE LEON SOLORIO
of disadvantages that the users have found in the language. So please send any
disadvantage you have found. Also if you prefered another OOL and why.
I will really appreciate your help. wo trher
:
R.A.L Williams
: I am making a research of the Eiffel language and I want to include a section
: of disadvantages that the users have found in the language. So please send any
: disadvantage you have found. Also if you prefered another OOL and why.
: I will really appreciate your help. wo trher
Eiffel is a great language but there are one or two niggles. Here's a list
of things which spring to mind (in no particular order):
Extending a method of a parent class (where the parent class has not
been written explicitly to support this) requires repeated inheritance.
Come to that, I still find the whole syntax of the inherit clause picky
and over-complex (mainly because its order sensitive and clumsy).
No 'overloading' of functions and operators. Paul Johnson (also of this
site) tells me that this could open a whole can of worms, but I'm yet
to be convinced; and there are many occasions, particularly in simulation
software, where overloading is a useful notation simplification.
No 'representation-level' semantics (unless you count the BIT n class, which
I certainly don't) ie. no bit-wise operations, no hex or octal constants.
No 'callbacks', or at least no easy clean way of implementing them that you
can guarantee will work (I must admit I've had no trouble with Eiffel/S,
but the manual is full of dire warnings).
--
Bill Williams |GEC-Marconi does not necessarily
GEC-Marconi Research Centre |endorse my opinions!
Matt Austern
> Although there are nits that could be picked, Eiffel has fewer than any
> other language I can think of.
Most of my objections to Eiffel come down to syntactic ones: in the
interests of simplicity, a lot of convenience features have been left
out. None of those features are in any sense necessary, but their
absence does make programming in Eiffel more tedious in some ways than
programming in other languages. No real reason why I should list those
convenience features; I think we all know what they are.
My only substantive objection to the language itself, and it's still a
pretty mild objection, is the lack of global functions and variables,
and, similarly, the lack of functions and variables that are
associated with a class instead of a particular instance of a class.
Again, this lack isn't crippling: everything that you would use these
features for in other languages, you can still do in Eiffel. The
workarounds you need to use in Eiffel, though, involve what I regard
as an abuse of the inheritance mechanism.
Finally, Eiffel seems to be missing a real module mechanism: I don't
see any way of specifying, in the language itself, that a group of
classes forms a single component and that some of the classes belong to
that component's public interface while others are purely for
implementation. (Clusters aren't really a substitute. First, they
aren't a concept within the language itself, but part of LACE.
Second, they're missing some important features that a module system
should have. Third, existing implementations don't even seem to have
the full functionality described in E:TL.) This isn't really an
argument against using Eiffel, since most of today's popular languages
also lack a real module system, but, in a language designed for
building large software projects, it's still unfortunate.
--
Matt Austern He showed his lower teeth. "We
ma...@physics.berkeley.edu all have flaws," he said, "and
http://dogbert.lbl.gov/~matt mine is being wicked."
BruceMount
>>I am making a research of the Eiffel language
>>and I want to include a section of disadvantages
>>that the users have found in the language.
Although there are nits that could be picked, Eiffel has fewer than any
other language I can think of.
Eiffel's main disadvantages have nothing to do with the language. The
largest problem with Eiffel is business and marketing. Eiffel is just
starting to appear in robust form on the (like it or not) most popular
platforms on the planet, PCs and Macs. Until the Eiffel tools and
environment reach a level of maturity similar to popular C++ tools, Eiffel
will not catch on.
The good news is that Eiffel vendors have made large strides in this area
recently. The bad news is further strides remain.
--Bruce
"Another member of the Eiffel Jihad!" :-)
Bruce Mount (br...@pls.com)
http://www.pls.com/
Matt Austern
> > and, similarly, the lack of functions and variables that are
> > associated with a class instead of a particular instance of a class.
>
> Well all functions and procedures are associated with a class. I'm
> not sure what you mean.
I'm referring to what C++ calls static member functions and variables,
and what Smalltalk calls class variables and methods. I suppose other
languages have similar terminology.
Eiffel doesn't have a direct equivalent. I'm aware that there are
techniques (including, for example, once functions) that allow you to
simulate these things; in many cases, though, they require some ugly
circumlocutions.
Paul Johnson
> My only substantive objection to the language itself, and it's still a
> pretty mild objection, is the lack of global functions and
> variables,
"once" functions do this job without the disadvantage of a global
namespace. To get a "global" object you define a once function that
creates the object and returns a reference to it.
"Global" functions can be created by simply defining them in a class
with no features. "MATH" is a good example.
> and, similarly, the lack of functions and variables that are
> associated with a class instead of a particular instance of a class.
Well all functions and procedures are associated with a class. I'm
not sure what you mean.
A variable associated with a class is basically the "once" function
described above.
> workarounds you need to use in Eiffel, though, involve what I regard
> as an abuse of the inheritance mechanism.
Ahh, you mean "inhert MATH". How about:
feature
math: expanded MATH;
-- More stuff ommited.
x := math.sin (y);
This mirrors the use/with argument in Ada.
Paul.
--
Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 473331 ext 2245+-----------+-----------------------------------------+
Work: <paul.j...@gmrc.gecm.com> | You are lost in a twisty maze of little
Home: <Pa...@treetop.demon.co.uk> | standards, all different.
Colin James III (The Rt Rev'd)
| Ahh, you mean "inhert MATH". How about:
|
| feature
| math: expanded MATH;
|
| -- More stuff ommited.
|
| x := math.sin (y);
|
| This mirrors the use/with argument in Ada.
The use/with argument in Ada is a nightmare in my opinion because it
is not only difficult to learn but the scope before/during/after and
benefits/disadvantages are so complicated that when a use/with error
is generated (rarely) by a smart Ada compiler, the fix can be
frustrating and utterly tedious to find (due to scoping).
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Colin James III, Principal Scientist cja...@cec-services.com
CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA
Voice: 303.231.9437; Facsimile: .231.9438; Data: .231.9434
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Humberto Hernandez
: My only substantive objection to the language itself, and it's still a
: pretty mild objection, is the lack of global functions and variables,
: and, similarly, the lack of functions and variables that are
: associated with a class instead of a particular instance of a class.
: Again, this lack isn't crippling: everything that you would use these
: features for in other languages, you can still do in Eiffel. The
: workarounds you need to use in Eiffel, though, involve what I regard
: as an abuse of the inheritance mechanism.
Then how do you do when you need class variables?
: Finally, Eiffel seems to be missing a real module mechanism: I don't
: see any way of specifying, in the language itself, that a group of
: classes forms a single component and that some of the classes belong to
: that component's public interface while others are purely for
: implementation. (Clusters aren't really a substitute. First, they
: aren't a concept within the language itself, but part of LACE.
: Second, they're missing some important features that a module system
: should have. Third, existing implementations don't even seem to have
: the full functionality described in E:TL.) This isn't really an
: argument against using Eiffel, since most of today's popular languages
: also lack a real module system, but, in a language designed for
: building large software projects, it's still unfortunate.
I was very surprised I did not find support for a module system
(may be namespaces) in Eiffel, as you say Eiffel was designed for
building large projects. IMHO this may not be a particularly
hard to implement feature, and it may help a lot with name conflicts.
So far in the brief peek at took at Eiffel this was the most
noticable missing feature. Yet, I still have high hopes in the
language.
Lorena:
Me gustaria leer el resultado de tu investigacion.
Te estoy escribiendo desde la hermana republica de
Chihuahua. Ajua!!
Ian Leonard
BruceMount <bruce...@aol.com> wrote:
>Lorena:
>
>>>I am making a research of the Eiffel language
>>>and I want to include a section of disadvantages
>>>that the users have found in the language.
>
>Although there are nits that could be picked, Eiffel has fewer than any
>other language I can think of.
>
>Eiffel's main disadvantages have nothing to do with the language. The
>largest problem with Eiffel is business and marketing. Eiffel is just
>starting to appear in robust form on the (like it or not) most popular
>platforms on the planet, PCs and Macs. Until the Eiffel tools and
>environment reach a level of maturity similar to popular C++ tools, Eiffel
>will not catch on.
>
>The good news is that Eiffel vendors have made large strides in this area
>recently. The bad news is further strides remain.
I think Bruce is right. If you want Eiffel to become "popular" you need
to decide what sort of programs the majority want to write. Then you can ask
what you need to do to make it appeal not only to those who design the
systems and write the code, but also to those who pay for them.
Lets assume you have the following markets:
(1) Scientific applications
(2) Large business applications
(3) Visually orientated stuff like word processors and web browsers
(4) System utilities like comms packages and mailers
Given that Oracle and Informix rank amongst the largest software companies,
business systems seem to be the biggest area. In other words there are
more programmers writing business applications that any other.
Following this logic, you need to appeal to two groups:
(1) the, shall we say, less qualified programmer, and I don't mean this in
any derogatory sense. If you want to write banking software, a knowledge
of banking might be more appropriate than five years of solid coding
experience.
In this respect Eiffel is too complex. It doesn't have the easy leadin
that C has.
(2) the man with the money. He needs assured that he won't get fired for
choosing Eiffel. One look at this news group and it'll be back to Oracle.
Programmers are too often hired for a specific job and then dumped. Managers
will look at experience and training requirements.
Eiffel needs to get software houses to take it on. For that you need,
to demonstrate the power of Eiffel in a five minute demo. You need books
(for teaching) and more that that you need applications and libraries.
At some point the Eiffel world has got to stop saying that Eiffel is the
best OO language and start saying that it is better than Oracle for developing
programs. Then, when someone asks why, you need to come up with some answers
that people can understand.
That's what I think anyway....
--
Ian
Ian Leonard eMail: i...@eonsw.demon.co.uk
EON Software Phone and Fax: +44 (0)1865 741452
Joe Borkoles
[snip]
>platforms on the planet, PCs and Macs. Until the Eiffel tools and
>environment reach a level of maturity similar to popular C++ tools, Eiffel
>will not catch on.
I wouldn't go on the maturity of C++ tools, in general they look better
in the brochures than in practice. Compared to Smalltalk they stink!
-----------------------------------
I speak for myself and no one else.
Burak Bayramli
>
>bruce...@aol.com (BruceMount) wrote:
>
>[snip]
>
>>platforms on the planet, PCs and Macs. Until the Eiffel tools and
>>environment reach a level of maturity similar to popular C++ tools, Eiffel
>>will not catch on.
>
>I wouldn't go on the maturity of C++ tools, in general they look better
>in the brochures than in practice. Compared to Smalltalk they stink!
True. I don't know about the Smalltalk part, never used it.
Borland C++ 4.5 last version has a built-in debugger and it has been around
for years right?? It still has a C debugger feel, I'll take Eiffel's assertions mechanism
plus a debugger like ISE's, anytime over Borland's. Too bad B. is advertising
themselves as leader i
>
>-----------------------------------
>I speak for myself and no one else.
>
>
**************************************************************
Burak Bayramli
Stevens Institute of Technology
http://menger.eecs.stevens-tech.edu/~bbayraml/
e-mail : bbay...@attila.stevens-tech.edu
**************************************************************