Interview With Bjarne Stroustrup

koval writes "artima.com has published an initial portion of interview with Bjarne Stroustrup. The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language."

Comments

From the article

[Apreche]

Quote Bjarne Stroustrup: Yes. If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions, and override it with the one and only representation. That's just elaboration. It's not necessary.

Thank You! This is the number one java peeve. Every time I just want to make a structure I've got to make a whole class. That's a whole file. That's a whole lot of extra code. In C/C++ I can make an equivalent struct in a few lines.

This is why I like python so much. I can do all the object-orientedness I want and all the proceduralness I want and they work together perfect. And everything pops out into super efficient C code and then into executable with my gcc. And if I want it cross platform I can just use jython and get workin .class files.

Re:From the article

[X]

You need to bone up on your Java, and perhaps your C++.

1. In C++, in terms of writing effort, a class and a struct are the same
2. In Java, you can have multiple classes in a single file. Indeed, the compiler could care less, just like in C++.
3. You can compile Java code to binary, indeed you can do so with gcc.
4. Try benchmarking Java vs. Python some day. You'll discover that aside from start up time, Java outperforms Python in the majority of cases.

This is the C++ code for a class:

class Foo {
public:
int bar;
int baz;
};

This is the C++ code for the equivalent struct:

struct Foo {
int bar;
int baz;
};

This is the Java code for the equivalent class:

class Foo {
public int bar;
public int baz;
}

Not a lot of difference is there?

Re:From the article

[Angst Badger]

I find that nearly everyone who criticizes [INSERT LANGUAGE HERE] is either using an ancient implementation ... or they simply haven't explored the language fully.

This is an excellent template for recognizing language bigotry. Try this as a template for recognizing language agnosticism:

"I can enumerate dozens of less-than-perfect features in my favorite language."

Until you understand the weaknesses as well as the strengths of your favorite language, you either haven't explored it fully or you don't know enough languages well enough to have a basis for comparison. (C|C++|Java|Perl|AWK|Python|COBOL|RPG|Fortran|BASI C|PHP|Forth|6502 Assembly|Forth) all suck if you're only looking at their flaws, and they all rock if you're only looking at their strengths. If you're not looking at both, you're not getting it.

The real trouble with C++

[Animats]

C++ suffers from the same problem that killed Pascal - its creator thinks everything is just fine, yet people are deserting it because it has some major problems that the creator refuses to fix and everybody has to work around.

We went through this with Wirth. Wirth devised Pascal, which had reasonable data structures, although not objects, terrible I/O, and strings that only worked if they were short. He then insisted that it shouldn't change. From this came a whole range of incompatible Pascal dialects (Turbo Pascal, Object Pascal, Clascal...), and some successor languages (Modula I, II, III). Modula III was actually rather good, but nobody except some researchers at DEC SRL (now an empty building in Palo Alto) used it. Two decades later, few use Pascal or its derivatives, and Wirth is a forgotten and bitter man in Switzerland.

This cycle is being repeated with C++. The first version of C++, before templates and the STL, was terrible. Without templates, horrible schemes involving huge defines were used to make generic objects. Strostrup used to have great hostility to run-time type information, which led to unchecked downcasts all over the place.

Round 2 of C++ came late, and it took a long time before the compilers did templates. Then came the STL, which is wierd and unsafe, although useful.

C has little abstraction and little safety. Java has both abstraction and safety. C++ has abstraction without safety, a terrible combination. The basic problem with both C and C++ is that the language requires the programmer to obsess on storage allocation and release, yet gives no assistance in this. Attempts to encapsulate storage allocation in C++ fail miserably (look at the history of auto_ptr). Attempts have been made to fix the language by adding another layer of rote ritual ("patterns") on top of it, but compilers can't check that, so it doesn't reduce bugs.

Another area of trouble comes from the history of C++ as a preprocessor for C. Bell Labs had a tradition that "you can't change the linker". (This is probably because the original UNIX linker was written in assembler and had few comments.) Because of this, some tasks that should be deferred to link time (such as building vtables) are done at compile time.

The price paid for not changing the linker is substantial. Private function members appear in header files so that vtables can be built at compile time. That's the real reason, despite what you read. If it weren't for that, you could have much stronger separation between declaration and implementation. And you wouldn't be recompiling class users just because the class implementation changed. Ada and Modula got this right, but C++ got it wrong. And Strostrup refuses to fix it.

Yes, there are "patterns" for working around this. But they're workarounds. The programmer is doing the compiler's job. This imposes a cost on every programmer and distorts C++ programs.

Strostrup still insists there's nothing really wrong with his language. Read what he's written about the C++200x standards revision cycle. Meanwhile, C++ is being abandoned for Java, C#, C, and scripting languages.

It's an education issue

[Anonymous Brave Guy]

Seriously, you can't seriously improve a language by telling people how to program with it.

However, you very much can improve how a language is used by telling people how to program with it. The single biggest problem C++ has isn't dangerous pointers, or ugly template syntax, or lack of a garbage collector, it's lack of good programmer education. C++ is a power tool, and requires skill to use. When most of the C++ textbooks in the world are teaching decade-old crap themselves, and most of the university professors don't know their own subject, it's not too surprising.

I can sympathise a lot with Stroustrup here. His tool is unjustly battered by the ignorant more than perhaps any other mainstream language today, and it creates a self-fulfilling prophecy: most people who learn C++ learn it badly, and write code with buffer overflows and other kindergarten mistakes. Others pick up on this, and learn from people who themselves learned badly, and write more code with kindergarten mistakes. It's about time the C++ programming industry reached High School, but few ever seem to, and when they do, they aren't valued as much as they should be.

Confirmed: C++'s not very object-oriented

[dpbsmith]

I'm not saying that's necessarily a bad thing.

The interview is interesting in that it confirms the impression I've had from using and/or struggling to use C++. When I try to do anything object-oriented, specifically anything involving polymorphism, it seems to be fighting me all the way. After some struggling I usually emerge triumphant, but it's almost always a battle.

What Stoustrup seems to be saying is that classes should be treated as a special big deal, and shouldn't be used unless you're sure they're necessary. He seems to be recommending that there be, um, a class of elite programmers who put in the intense work to develop good, usable, well-debugged classes, and that the rank and file should, by all means use those classes but should not aspire to write new ones.

And this is not unreasonable, given the effort of writing classes and getting the storage management right and so forth.

The thing is, it's not a big deal to use classes in a truly object-oriented language. I'm not just talking about Smalltalk. Heck, they're trivial to use in REALbasic.

Well, is that good? It certainly leads to overuse of OOP. To a man with a hammer everything is a nail, and every programming language tends to encourage overuse of the things that it facilitates. Every programming language has a tendency to induce brain-warp.

C++, for better or for worse, does not induce object-oriented brain-warp.

People who try to use OOP in C++ because it's cool or because of some article they read (or some instructor they had) find that C++ punishes such behavior. And Stoustrup is right: when you are programming in C++, OOP should be used sparingly and only when it's needed.

Again, I'm not saying whether that's bad or good. That will depend on the degree to which you think OOP ought to be encouraged. If you think OOP should be just as much a part of a programmer's mental toolbox as iteration, or recursion, then it's not good. If you think OOP was the overhyped IT fad of the nineties, then it's not bad.

What I'm saying is that it has always seemed to me that C++ is not a very object-oriented language, and Stoustrup's remarks seem to me to confirm the objective validity of that observation.