Bertrand Meyer And His Opinions

BertrandMeyer is noted for his strong opinions...

C/C++ Programmers

See the discussion of Meyer's article BewareOfCeeHackers ("But in general you should be cautious about including C hackers in your projects").

C++ language

Meyers thinks that it is utterly broken, since it messes up MultipleInheritance, it does not have automatic GarbageCollection, it does not have ConstrainedGenericity?, it uses type casts, it uses overloading. He also think CeePlusPlus goes against a basic methodological principle by providing lots of features together with "Never Do This" suggestions.

Can he provide a language that stretches so far, from super-tight compilation to a wide range of flexible expressions? --PhlIp

Multiple Inheritance

Meyer always sustained that SingleInheritance is dumb, for example: "The absence of multiple inheritance in Java precludes using many of the most useful patterns of object-oriented development, which combine several abstractions into a new one".

"Never Do This" suggestions Meyer goes at great lengths in ObjectOrientedSoftwareConstruction to highlight why approaches like "you should never use this feature of the language/tool" are wrong. The basic idea is that you should either

make this hint part of the language/tool
remove the features
use another tool

Examples of this may include C/C++ type casts, complex hierarchies in environments with MultipleInheritance without clean disambiguation, or without a good method lookup algorithm, eval-like functionalities, case sensitivity (since it allows Foo and foo to be different but this is considered bad), GoTo statements, possibly public member variables always made private with accessor methods, and many others.

Some of Meyer's criticisms of C++ in this regard strike me as a bit specious. The issue with case sensitivity, for instance - this strikes me as similar to arguing over which endianality is "better". (That said, I suspect that internationalization will ultimately drive languages towards case-sensitivity; as case conversion of many international character sets gets quite tricky). Some of the other things - "C++ type casts", for instance, are present in the language for backwards compatibility, or are only intended for specific applications (and come with implicit "warnings" attached, i.e. reinterpret_cast.) "Eval" is, of course, not present in C/C++. Et cetera...

Note that the examples are not specific critiques to C/C++, for example they extend to Java, Python, C#, Scheme. Notice that he *is* guilty of this, since the convention used in naming for Eiffel (CAPITAL_CASE for classes, snake_names for methods and variables) is not enforced but you are suggested to always use that. The "implicit warning" is obviously a proof of Meyer's view, you are providing a feature and telling people to not use it, so why did you provide it in the first instance? (The answer of "backwards compatibility" is not a good one since Meyers' Eiffel can work with old C libraries without allowing unsafe type casts.)

He surely hates C++, but I think he does since he found this kind of reasons, not that he found reasons since he'd been hating C++.

UML (UnifiedModelingLanguage)

BertrandMeyer has a go at UML: http://www.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html

...but seriously, in defense of UML:

You don't have to blow the budget on CaseTools - UmlIsForPeople.
Inflexible, dictatorial methodologists have caused an enormous amount of unnecessary confusion - saying "no, use my notation!" isn't a solution - it's the cause of the problem that the UML attempts to solve.
A standard notation was long overdue. Real world standards are messy - could anybody produce a simple standard notation with the same goals?
The BusinessObjectNotation (BON) uses CrcCards, but it takes exactly the sort of dictionary approach that is criticized in "TheAlmightyThud".
If Walden and Nerson (of the BusinessObjectNotation methodology) wanted to contribute to the UML I'm sure they could have made submissions to the OMG. (Don't whinge about the UML - improve it!)

Maybe more people would embrace BertrandMeyer's ideas if he didn't make such extreme statements.

(With all due respect to BertrandMeyer who has made a number of useful contributions to our field.)

More debate at BonVsUml.

On SmalltalkLanguage:

: The lesson is clear: it would not, in my opinion, be reasonable today for a company to entrust a significant production deployment to Smalltalk. -- ObjectOrientedSoftwareConstruction, volume 2, page 1130

Anonymous Refereeing

BertrandMeyer is opposing the anonymous refereeing process that is standard in the scientific community. He always signs his reviews and makes the conference organizers forward this signature with this review to the authors.

See: http://www.inf.ethz.ch/personal/meyer/publications/online/whysign/

The one thing we can all expect from BertrandMeyer is his strong ideas and extreme statements. I, for one, think they are refreshing (even when I don't agree).

I start to worry when everybody is toeing the line. Every once in a while I need that smack up side the head by those with dissenting ideas. -- ToddCoram (raised on ChuckMoore's radical Forth ideas).

I just came across this in TheLiterature?; it made me literally laugh out loud, and I thought I would share:

Eiffel borrows quite heavily from some earlier programming languages and I am sure that if we had found a good programming construct in C we would have used it as well.

Funny, but snide. Goes hand in hand with his "But in general you should be cautious about including C hackers in your projects"

From the website: Is it true that Eiffel Compiles into C?

Yes. The Eiffel compiler generates an internal form known as "bytecode". The bytecode can be interpreted directly, but it can also be translated into other forms.

To generate the final version of a system, the bytecode is optimized and translated into C, to take advantage of the presence of C compilers on just about every platform under the sun. This is the process known as "finalization", which performs extensive optimizations (routine inlining, static calls, array optimization), permitting performance achievements.

Hrmm. so it was created by hackers, in C, but it's not for hackers?

Correct. The C code is the output of an optimizer. If someone suggests you shouldn't hack machine code directly, you can't criticize her for using a compiler.

B. Meyer used to be a fairly visible OO evangelist. But, he has been quiet lately. What's up?

Easy. He neglected to pay attention to TypeTheory while designing EiffelLanguage, and as a result, committed one of the famous LanguageTypeErrors. EiffelLanguage has not been the success he hoped. That's one theory.

But he still says it's choice is right. "The world is covariant" is still written in a not-so-old paper:

http://se.ethz.ch/~meyer/ongoing/covariance/recast.pdf

Or he could be busy doing teaching and research, and not have time to be a high-profile advocate for Eiffel.

In my opinion it is all about ambiguity and encapsulation and finally re-use. In C we find that we have to try hard to encapsulate or re-use something to make it work multi-threadingly or multi-processingly. In C++ we find that we have multi-threading-support and multi-process-support along the way because of the runtime environment of what the compiler creates.

Yet, in C++ we also find much ambiguity or rather side-effects resulting from that "ambiguity" in respect to for example references to objects that have been destroyed (deleted) and other instances of objects still requiring these objects to be available. As such, the runtime environment of the C++ language was never really absolutely fail-safely defined, at least in my opinion.

Next we have the templates that are not compatible in derivation and casting, as each template being concretized (correct word/spelling? - correct me!) cannot be cast to another template of the same base template or a template in a hierarchy in templates without losing context, i.e. dynamic_cast to void or other types.

Yet, I am no expert in C++ but I have found out that I'd rather not use this language anymore unless it becomes more dis-ambiguous in language terms.

The same with constness in C++. You can always const_cast something to be finally mutable. But how would one consider something to be const_cast to be finally mutable, the term in itself is ambiguous and finally misleading.

Yet, I still think that Bjarne Stroustrup did a great job, yet he failed when it came to language in itself.

And, yet, still more I feal that C is inherently less ambiguous than C++ because of the above and that C can be much more rewarding than using C++ and finally debugging C++ which is finally a trial&error experience.

But I also don't think that Eiffel is the cure to all programmers pains. At least in my opinion.

-- CarstenKlein