Slashdot Mirror
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."
How about eliminating the buffer overflows?
BOO! TERRO
Any language that allows for someone making a living pointing out everything one shouldn't do needs more than a face-lift.
I used to wonder what was so holy about a silent night, now I have a child.
Oh boy! I can't get enough of Bjarne and J-Lo!
Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.
Interviewer: problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty.
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen.
Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better.
Stroustrup: Exactly. Well, the same happened with 'C' programmers.
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.
[NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)]
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do.
Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.
Interviewer: I don't believe you said that...
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code?
Interviewer: Well, never, actually, but...
Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about '90 or '91. I felt sorry for them really, but I thought people would learn from their mistakes.
Interviewer: Obviously, they didn't?
Stroustrup:
Speaking of C++, is there a compiler that complies with the ISO standard already? Does anyone use it?
Save your wrists today - switch to Dvorak
Where do you see C++ going as a language?
I think I'll just clarify that. In four or five years, what changes would you like to see happening to the language, and how realistic it is to be able to achieve those goals in that time period?
I have over 70 freaks, do you?
I see that a lot of people here are confused and posting questions for Bjarne Stroustrup. This is not a slashdot interview where people post questions for the guru and the editors pick the top 5 for the interviewee to answer. This is an interview that was done by an external website and not interviews.slashdot.org.
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.
.class files.
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
The GeekNights podcast is going strong. Listen!
All he did was complain about over and under object-orienting c++ code. Not sure why that's useful... My Computer Science professors do that all the time.
Being that there is a large codebase out there that breaks either one of these rules I would venture a guess that is why he commented on it. He does not believe that there is a sliver bullet to solving software problems nor does he believe that C++ is one either. It is just a language he designed to solve problems he encountered while programming.
C++ is not object oriented. It has OOP support but does not mandate it. The other extreme is that it is not C. If you find yourself falling to one of these extremes in *EVERY* coding probem then there is a high probability you just might have missed his point.
BSD is designed. Linux is grown. C++ libs
Real men code in assembler
Since when did Steve Gibson start posting here as an Anonymous Coward?
Some people use a screwdriver, others use a butter knife. That's the beauty of programming; there are numerous tools and technologies at your disposal that will all achieve the effect (or at the very least, a semblance of the effect) you desire. Business users typically don't know the difference anyway, so it's really a matter of programmer's preference. Pick those you feel most appropriate to your project, and leave the rest.
Most people I know don't get the beauty of something like C++. It's a massively complex language. So complex, as a matter of fact, that you can create OTHER languages with it (via templates). But, like any other, tool or technology, take what you want from C++, and leave the rest behind.
Spread the RC luvin'
I went to one of this guy's conferences on C++. I thought it'd be more in depth, but it was merely introduction to the features of C++. It does this, it does that. Neat libs like boost and the stl. Also has ACE libs for cross compatability
Well, as one may expect, someone asked about java. He got very biligerant and brief about it. "C++ is supported on N many more platforms than java." (Can't remember N). It was also the last question too, which left that "weird" sense in my mind's eye.
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
Stroustrup and the interviewer miss one important point in the class vs. struct and invariant discussion: binary compatibility. The reason why you should not access variables in structs/classes directly is not always that their representation may change. More often it happens that you need to add a member, but this is not possible without breaking binary compatibility (at least on the usual Linux/Unix compilers). So you need to use the private class/d-ptr pattern to hide at least future members from the public class. This does not break apps that use the class members of earlier version, but it would make the API inconsistent, as the newer version would need to offer a different way of accessing the members. And the easiest one is to have get/set methods. So if you don't want to fall into the inconsistent API trap later, you should use get/set methods from the beginning. It's the only chance to have a consistent API over several evolving but still binary compatible versions.
Try his FAQ: http://www.research.att.com/~bs/bs_faq.html#Java
I've always liked C++. After reading about half (still working on the rest of it) of "The C++ Programming Language" by Bjarne, I've learned so much about what good C++ programming is about. During University, the C++ class I took covered so little. It was basically a C course except we implemented yet another string class. This book is great. Bjarne comes across as a really smart and logical person. The last few chapters about design are great. I skipped up to them after reading the first 2 sections or so. I love reading interviews of him and things he's written. Everytime I work on a personal project I try to add another idea he presents to my own work.
I seriously enjoy programming in C++.
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.
I mis-read the title. Thought it said "interview with a mousetrap"
oooops...
So rise up, all ye lost ones, as one, we'll claw the clouds.
I programmed in C for years, mostly due to the performance of the early machines I used. Today, I wouldn't consider going back to C unless it was for time critical functions. Everything I do these days is in an environment that protects me from the gory details of memory management and pointers of doom. If I really need performance, I am going to profile my code and find the parts that really need the boost, and then recode the classes as C++ COM or more recently C++ assemblies for .NET. It is the same procedure I used to use when C was my primary language: find the performance hot spots and drop to assembly if needed.
The discussion of class design has nearly nothing to do with C++. I can use Java to build overly complex towers of inheritance. I can also use it to build poorly defined libraries. One think I *can't* easily do is blow myself (and the underlying OS) up do to a memory allocation problems.
I see C++ remaining for many years to build those "cycle critical" components, which are going to be consumed by languages with a guard over the chainsaw blade. Programmer efficency should always trump speed concerns until you have exhausted *algorithmic* improvement. I don't know how many times I see programmers saying "I'm using C++ for performance" while simultaniously writing something that is going to run in o(n^2) time, when a o(log(n)) algorithm is available. Yes, your C code will run your inefficent algorithm quicker than I would in a protected environment, but if my protected environment allowed me to see the abstraction that runs the fastest algorithm, my code will still be faster for large data sets.
Sig under construction since 1998.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Fully encapsulating the complexity of an abstract data type without just giving up and making many of the important decisions in the language itself is an extremely difficult problem in language design. I find the first poster's sentence, while obviously an exageration, to be rather insightful.
C++ has high aspirations in terms of giving the programmer complete control but ultimately fails due to the emergent complexity that results from the inability to fully encapsulate all of the design decisions.
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.
"How to Do Nothing," kids activities, back in print!
Come on. If you're talking about vectors, lists, sets, queues, stacks, hash_maps, etc., then I think the STL does, via templates, quite a stunning job of encapsulation. Stroustrup's comment in the article concerns wider adoption of the STL as a starting point for more developers, and I challenge straightforward applications developers to disagree with that. In reviewing others' code, I'm frequently surprised to see arrays being used where vectors or lists would suit as well and be safer, and frequently disappointed to see many functions implemented without templates where they could be effectively abstracted and made much more reusable (and refactorable, if that's a word) by using templates. Please tell me where vectors, as an example, fall short in the encapsulation goal.
Where have other languages succeeded? Java provides a base int type and an Integer wrapper, and this is a fundamental data type. Is this success? I just think it's confusing. And what about operator overloading in Java? Yes for Strings but no for user types? I think operator overloading, in a dedicated OOP language of all things, is very important to encapsulation, but Java says "too dangerous"!
Rubbish. And I'm not really meaning to pick on Java. My overall point is that on an application level there is a pie-in-the-sky goal that might be feasible in terms of encapsulation and that's what I believe we should strive for. But on a library or language level, saying C++ is at fault for not ensuring "perfect" encapsulation (and I'm not sure what that is) throughout the libraries is a little naive. Please point out the language that gets anything fully correct without sacrificing something else. I mean, isn't this why we have different languages for different things?
Finally, I don't find that sentence insightful. Saying C++ is "without" safety is only illustrating a complete lack of familiarity with the STL. The programmer does have to keep track of things at times, but nothing even approaches real difficulty until you start creating your own ADTs. Mainstream types of the "Shape" or "Person" or "Animal" ilk are fine and dandy and really no more difficult or "dangerous" than Java or C#. It's not until you get into the implementation of things like "vertex_queue" or "parallel_list" that you, admittedly, start to get into much slower going territory. But there's also a lot of power there, too, power that's taken away in other languages, such as Java, because it's too "dangerous".
Chr0m0Dr0m!C
If I write something like:
class F {
float a;
public:
F(float a0) : a(a0) { }
template<class X> X operator()(X x) const { return X(a)+x; }
}
is it OOP? It looks like OOP: it has a member variable, a method, a constructor and so on. But actually I'm defining a function closure. In Haskell you coud write an F(a) object as (a+).
My point is this: for many programmers today objects are often a(n awkward) vehicle for computing with closures. This has many payoffs: it gives the ease of functional programming but also potentially provides many performance benefits. I code like this all the time as do hundreds of others. This is how you need to code if you actually want to do anything non-trivial with the STL.
So in some sense I'm an OOP programmer. But in another sense I'm not. I'm not writing my code this way because I want to work with objects - I do it because this is the only way I know to treat a polymorphic function as a first class object in C++. Really I'm a functional programmer forced to use C++. It seems to me that many of Bjarne's remarks are way off the mark for programmers like me. We have to define classes for every damn little thing!
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
If you hate C++, it's unfair to suggest you read a book on it. But if you have any fondess for C++, or use C++ (even if you dislike it), Design and Evolution of C++ is probably worth your time. You learn why C++ is the slightly confusing mess that it is, and why Stroustrup believes it's the only way it could have succeeded. Having a grasp on why C++ is C++ (and not Objective C or Java) can improve your C++ coding abilities. And understanding why behavior you don't like is there can at least help minimize the suffering ("This is stupid, but there really isn't any way to change it.").
Search 2010 Gen Con events
I think perhaps there's a misunderstanding in the grandparent post. Stroustrup, and others on the standards committee, are on record as saying that they don't see the need for many language changes. They do, however, propose to make extensive library changes. Their reasoning is simply that there is likely to be more than one sensible way to approach topics such as, say, concurrency and synchronisation, and thus building them into the language itself is unduly limiting.
If you go to Stroustrup's home page (sorry, don't have a link handy, but it'll easily Google) and then look for his comments on C++0x, I'm guessing the slides from his presentation describing the above are still available.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
True, you can fail to release resources, but in many cases it is handled for you in garbage collected languages by scope. That transparent handling probably is a big source of problems for those unaware of the problems of holding on to references beyond the scope necessary, but what I was refering to was the fact that I can't easily set a pointer up that points to incorrect memory locations and causes a subtle, usually non repeatable, near impossible to find bugs. Granted, tools like bounds checking software can help, but if I take a pointer to an object and then allocate some other objects and release a few, in C or C++ I can easily clobber my earlier object, causing modifications to it to do nearly random changes to other objects. Especially if you have a couple levels of indirection going. Maybe I just suck, but I have blown past the ends of arrays of more times than I probably should admit.
Sig under construction since 1998.
What C++ really needs is more features... LOTS more features. The language is not "rich" enough. C++ should add many other features to its syntax.
- For example, the ability to name identifiers with any character in any character set.
- As C++ is not complicated enough, we need a way to dynamically create syntax. It would work like operator overloading, but much more complicated. And it would be called Syntax Overloading. For example, the code, ("for (" class "in" class ")")() { [insert code here] } would allow you to specify a new type of for loop with your own syntax. The compiler, upon reading this line, would add the new syntax to its language rules. Then, you could type for (className in otherClassName) { some.code.here(); } and it would work as expected.
- The language desperately needs some built-in cryptography functions. For example, the function const unsigned void do_it(const unsigned short void const crypto % arg) takes one parameter, arg, which is encrypted inside a processor register and cannot enter main memory for security reasons.
- More complicated template syntax is needed. For example, suppose you want to create a class that is unknown at compile time... obviously, a way to specify runtime template processing is desperately needed.
- Support for returning multiple return values from a function. For example, the function const unsigned short, const int *, const long long grok_the_file(void) might return three different return values, seperated by commas, as in, return i, j, size; Oh yeah, and you could specify functions that return an unknown number of values using ellipses, as in unsigned short... function_name() or simply
... function_name(). Suppose you want to call a funciton that takes 3 parameters... you could instead pass it one function that returns 3 return values and C++ would know what to do with it.
- C++ needs a reserved word, like please_reconsider_cast, or something, that uses common sense to figure out what the heck you're trying to typecast into what, so that even if the code is faulty, the compiler will figure out what you really mean.
These are all just a drop in the bucket. C++ is obviously too small and simple of a language.I develop in both C++ and Java, and while I like both, it's pretty obvious to me that particularly for Junior and Intermediate level developers, Java development is significantly faster. Java's execution model also makes it much easier to design, implement and use frameworks and libraries. This in terms leads to faster development as well.
While for certain types of problems (for example anything requiring unsigned arithmetic), it's very difficult for Java to outperform C, in other cases I've seen computationally intensive Java code that was written in a few days get within 10-20% of the execution speed of C code that was written in a month (and this was prior to JDK 1.4). That level of performance difference, particularly with reduced development times (which give you more time to improve the efficiency of the overall design) makes Java a worthwhile candidate for a large chunk of the projects out there.
The sad truth is, a lot of C++ programmers are *not* at the skill level Bjarne is talking about. If even most C++ programmers were at that level, you'd suddenly find that C++ is a far better language to work with. Until programmers reach that level, it is a needlessly complex language which provides few useful advantages over it's competitors.
sigs are a waste of space
I think you make an interesting point about a lot of this depending on the quality of C++ programmer, and I would extend that to admit that there are certain level of programmer that will always need a simplified environment, and that's fine.
But for professional developers, wouldn't it be best if we just focussed on making he best tools and educating our industry to use them properly?
I mean, if you look, there are a lot of tools of convienience in the hardware store that professional builders don't use. You can duct tape something and it's good to go, but that's not what you train engineers... though they might use duct tape in a pinch.
I think you might be onto something about Java for newer programmers. I already have learned about all the things Java is to save me from, like the ins and outs of memory management, so I don't notice an speed up when I code in Java. The kinds of bugs I have to hunt in my stuff is not particularly addressed, and can't really by, by any language.
If a java program was written in a couple days, and the C equiv in a month... that implies something. There is not that much difference in the language. That sounds like library availability, the C programmer had to write something that was already available in Java, which begs the question... was there a good library available they didn't know about and could they have used C++. The 10% would still make it a better tool and worthwhile.
But where we really will probably have to agree to disagree is just on the "needless complexity" issue. That needless complexity is C++ giving you more than you need --- so you can decide what you need and have a wide range of paradigms under which you can code. That is C++ not trying to second guess for you. If C++ give an automagical solution, it also give no-solution so you can build your own automagic. If you don't like cout, there is still printf and if you don't like exceptions, it's up to you and your Coding Standards to decide is you have to use them.
It's that old choice vs. chaos. Personally, I can handle the chaos of choice.
-pyrrho