October 30, 2003Bertrand Meyer's interviewEiffel 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: 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: 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".
Posted by cedric at October 30, 2003 07:38 AM
Comments
Your language posts are very interesting. Any chance of comments on Groovy and BeanShell? cheers Posted by: lurker at October 31, 2003 01:41 AMI admire your willingness to take on sacred cows of the OO world, like Bertrand Meyer and Eiffel. Keep it up! Posted by: Anonymous Coward at October 31, 2003 06:45 AMIs it too late for me to write sensibly, or is the complete text duplicated twice in your post? Posted by: Stefan Tilkov at October 31, 2003 04:39 PMOne of the aspects of Java I've always admired is its feature set. Starting from almost nothing, the designers had to decide on syntax, structure, features, and also write basic libraries. What stands out about Java is not what the designers put in, but what they left out. Everyone has one or two features from another language they'd like included in Java, but few people find Java so lacking that they can't develop with it. Java is a far more inclusive language than many others, helping developers avoid mistakes so common in other languages. Many of the most confusing and most often misused features were left out of the language. Java makes it easier to write good code. Eiffel, too, is noted for the decisions involved in its design. Wherever Meyer had to make a decision, he didn't. He just included the feature. Eiffel lets you do everything you'd ever want to do with Exceptions, but the implementation is terribly complex. Generics? Sure. Polymorphism? No problem. How about late binding, design by contract, invariants, explicit tuples, self documenting code, redefinition, multiple inheritance, even deferred classes. At least they left out GOTO and pointers to memory. In the hands of a brilliant developer, Eiffel is a powerful tool. But given that many of the people with whom I work are not brilliant developers, I prefer that they use Java. Far, far fewer opportunities to shoot themselves in the foot. Posted by: Eric Hancock at October 31, 2003 06:04 PMAh poor old Bertrand. He spent 10 years raging that C++ was such an evil abortion of a language, and Eiffel was so pure and beautiful. A veritable King Lear of the programming world, he could never understand the stupidity of so many C++ programmers. Debates between Meyer and Stroustrup were always fun. Meyer would do his usual C++ is rubbish, and Stroustrup would just sidestep the argument, and say he wasn't providing the world with a pure OO language. That said, he wrote a great book, and I still remember the Eureka effect I had when I saw how undo could be implemented by reifying the command. Of course, everybody knows this stuff, but back in the late 80's it was very clever. The other thing I liked was his class library for collections. At the time it seemed as if he had come up with a fundamental building blocks for collections. Its probably been superceded by the C++ STL. Posted by: Jonathan at November 3, 2003 10:06 AM>> For example, in just about every recent It's called encapsculation and is generally It doesn't sound like Meyer is indicating that
So lack of acceptance in the industrial world => >> Readability is also enhanced when overloading
> Besides, I happen to know for a fact the That might have been the initial motivation, but > Bertrand can rest assured: anyone who sees an It sounds like you had a not so good experience Post a comment
|