Eiffel inventor, Bertrand Meyer, gave an interview on artima recently. He makes reasonable points in the first two parts.
And then he mentions Eiffel (which he never fails to do).

I learned Eiffel in college a long time ago and it was quite an ordeal.  I
suspect the tools have improved quite a bit since then but the
language itself remains a puzzling mix of very questionable design choices for
an object-oriented languages, such as renaming imports a syntax that will
make you miss C++.  A lot of these features made sense back then when we
didn’t know better and Java didn’t exist, but I would argue that by now, we have
a pretty good idea of which object-oriented concepts are sound and which ones
should stay in the realm of academia.  As far as I
can tell, Eiffel hasn’t really learned these lessons as of today, but that’s not
the point of this posting.

Eiffel is vastly different from the C++/Java family
of languages, and there are undoubtedly dozens of different things you could
discuss in such an interview, but instead, Bertrand tries to make the point that
assigning fields is evil:

For example, in just about every recent object-oriented language, you have
the ability, with some restriction, of directly assigning to a field of an
object: x.a = 1, where x is an object, a
is a field. Everyone who has been exposed to the basics of modern methodology
and object technology understands why this is wrong.

Well, no.  Just saying "everyone understands it’s wrong" is not going to
make it suddenly a reality.

Without even discussing whether this is a good point or not, reducing 
most of the complexity of today’s software base to this simple concept is
laughable. And the quasi non-existence of Eiffel in the industrial world since
its inception (almost twenty years now) doesn’t seem to bother Bertrand Meyer at
all about the validity of the choices he made when he designed Eiffel.

Eiffel sports some very amusing archaisms, such as the absence of
overloading.  The
justification is worth a read (from the
FAQ):

Readability is also enhanced when overloading is not possible. With
overloading you would need to consider the type of the arguments as
well as the type of the target before you can work out which feature
is called. With multiple inheritance and dynamic binding this is
awkward for a compiler and error-prone for a human.

"awkward for a compiler"?  Now that’s a good one.  Code is code. 
It might be a difficult problem to tackle, but refusing to implement overloading
and choosing instead to support multiple inheritance of implementations makes me
wonder about the sanity of the ISE engineers.

Even now,
Bertrand Meyer is certainly still convinced that overloading is evil:

This kind of apparent short-term convenience buys a lot of long-term complexity,
because you have to find out in each particular case what exactly is the
signature of every variant of an operation.

Well, this is called a "paradigm shift".  And by the way, the
paradigm shifted at least ten years ago, and I can guarantee that by now, programmers are pretty much used
to read polymorphic overloaded methods.  Especially with modern IDE’s.

Besides, I happen to know for a fact the original motivation for leaving overloading out
of Eiffel (my teacher was a close friend of Bertrand Meyer).  Back then,
Eiffel was generating C, and overloading is not supported in C.  Of course,
it never stopped the original C++ compilers (cfront) from solving this problem,
but it looks like the ISE engineers have decided that this problem was too hard
for them.  And they haven’t revisited their choice since 1985.

Finally, one last gem:

“if it looks too good to be true, then it must not be true,” which is certainly the stupidest utterance ever proffered by humankind. This is the kind of cliche
we hear from many people, and it’s just wrong in the case of Eiffel.

Bertrand can rest assured: anyone who sees an Eiffel program for the first time will definitely not think “it’s too good to be true”.

Eiffel inventor, Bertrand Meyer, gave an interview on artima recently. He makes reasonable points in the first two parts.
And then he mentions Eiffel (which he never fails to do).

I learned Eiffel in college a long time ago and it was quite an ordeal.  I
suspect the tools have improved quite a bit since then but the
language itself remains a puzzling mix of very questionable design choices for
an object-oriented languages, such as renaming imports and a syntax that will
make you miss C++.  A lot of these features made sense back then when we
didn’t know better and Java didn’t exist, but I would argue that by now, we have
a pretty good idea of which object-oriented concepts are sound and which ones
should stay in the realm of academia.  As far as I
can tell, Eiffel hasn’t really learned these lessons as of today, but that’s not
the point of this posting.

Eiffel is vastly different from the C++/Java family
of languages, and there are undoubtedly dozens of different things you could
discuss in such an interview, but instead, Bertrand tries to make the point that
assigning fields is evil:

For example, in just about every recent object-oriented language, you have
the ability, with some restriction, of directly assigning to a field of an
object: x.a = 1, where x is an object, a
is a field. Everyone who has been exposed to the basics of modern methodology
and object technology understands why this is wrong.

Well, no.  Just saying "everyone understands it’s wrong" is not going to
make it suddenly a reality.

Without even discussing whether this is a good point or not, reducing 
most of the complexity of today’s software base to this simple concept is
laughable. And the quasi non-existence of Eiffel in the industrial world since
its inception (almost twenty years now) doesn’t seem to bother Bertrand Meyer at
all about the validity of the choices he made when he designed Eiffel.

Eiffel sports some very amusing archaisms, such as the absence of
overloading.  However, contrary to Ruby’s take on the subject, the
justification is worth a read (from the
FAQ):

Readability is also enhanced when overloading is not possible. With
overloading you would need to consider the type of the arguments as
well as the type of the target before you can work out which feature
is called. With multiple inheritance and dynamic binding this is
awkward for a compiler and error-prone for a human.

"awkward for a compiler"?  Now that’s a good one.  Code is code. 
It might be a difficult problem to tackle, but refusing to implement overloading
and choosing instead to support multiple inheritance of implementations makes me
wonder about the sanity of the ISE engineers.

Even now,
Bertrand Meyer is certainly still convinced that overloading is evil:

This kind of apparent short-term convenience buys a lot of long-term complexity,
because you have to find out in each particular case what exactly is the
signature of every variant of an operation.

Well, this is called a "paradigm shift".  And by the way, the
paradigm shifted at least ten years ago, and I can guarantee that by now, programmers are pretty much used
to read polymorphic overloaded methods.  Especially with modern IDE’s.

Besides, I happen to know for a fact the original motivation for leaving overloading out
of Eiffel (my teacher was a close friend of Bertrand Meyer).  Back then,
Eiffel was generating C, and overloading is not supported in C.  Of course,
it never stopped the original C++ compilers (cfront) from solving this problem,
but it looks like the ISE engineers have decided that this problem was too hard
for them.  And they haven’t revisited their choice since 1985.

Finally, one last gem:

“if it looks too good to be true, then it must not be true,” which is certainly the stupidest utterance ever proffered by humankind. This is the kind of cliche
we hear from many people, and it’s just wrong in the case of Eiffel.

Bertrand can rest assured: anyone who sees an Eiffel program for the first time will definitely not think “it’s too good to be true”.