Bjarne Stroustrup Reveals All On C++
An anonymous reader writes "Bjarne Stroustrup, the creative force behind one of the most widely used and successful programming languages — C++ — is featured in an in-depth 8-page interview where he reveals everything programmers and software engineers should know about C++; its history, what it was intended to do, where it is at now, and of course what all good code-writers should think about when using the language he created."
C++ is a woman?! I didn't see this coming.
Print Version of the same article http://www.computerworld.com.au/index.php/id;408408016;fp;16;fpid;1;pf;1
It's always cool to see this kind of interview. It's even cooler when you can read it all on one page rather than 8.
I suggest that anyone who uses C++ or is interested in the history of programming read this. Some of it is a bit banal, like how they chose the name, but some of it is really intersting. RTFA for once, you lazy clods!
C++ is a language of a million gotchas. The moment I start having to think about implementation detail and I'm not writing an operating system or compiler, I know I'm using the wrong language.
in an 8 page interview? I feel like a sucker for buying the 900 page book
More music, fewer hits
... for an equally partisan view from another perspective, the C++ FAQ.
programs in C++ could be simultaneously elegant ... and efficient for systems programming... Obviously, not every program can be both and many are neither
Many are neither. Ain't that the truth.
Best Slashdot Co
On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's Computer magazine.
Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created.
By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, for the good of the industry, but, as with many of these things, there was a leak.
Here is a complete transcript of what was was said,unedited, and unrehearsed, so it isn't as neat as planned interviews.
You will find it interesting...
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 - re
The pun seems to be that KDE isn't structured, efficient, portable or serious, despite being written in C++. I can't blame you for missing it, or finding it not funny.
Inaccurate. You forgot COBOL. But that's understandable, I want to forget it, too.
First, read the printable version of the article on one page. The original version is one paragraph per page, surrounded by ads and related dreck.
There's really nothing new there. It's the usual Strostrup stuff. He's still in denial about C++ being the cause of most of the buffer overflows, system crashes, and security holes in the world.
The fundamental problem with C was the "array=pointer" concept. If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant array parameters. That should have been fixed in C++, but it wasn't, and as a result, we had two more decades of buffer overflow problems. This isn't a performance issue, by the way; Modula 3 got it right, but Modula 3 disappeared for non-technical reasons - Compaq bought DEC and closed down the software R&D operation.
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
Yes, some of these problems can be papered over with templates. The C++ committee is full of templateheads, focused on template features that few will use and fewer will use correctly and productively. That crowd is still struggling to make auto_ptr work.
* No standardized pragmas
* Macros after-thought and not type safe
* No 24, and 32 bit (unicode) chars
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
* No distinction between typedefs and aliases
* Inconsistent left-to-right declarations
* Compilers still limited to ASCII source
* No binary constant prefix (even octal has one?!)
* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time
Bjarne Stroustrup Reveals All On C++
You mean... He's been holding back?
If you do what you always did, you get what you always got.
I'm afraid that web site is one of those things that gets way too much attention in some on-line communities because of its controversial nature.
The reason the two sides are far from equally partisan is that Stroustrup freely admits there is another side to the debate and that C++ has its flaws, and he is making efforts to improve the situation. The FQA, on the other hand, just makes blanket statements like "For example, the lack of garbage collection makes C++ exceptions and operator overloading inherently defective", which simply isn't true (and neither are many of the statements made in the FQA under those particular headings).
If you read the comments the guy who wrote the FQA makes on forums like reddit, as well as throughout the FQA itself, it's pretty obvious that unlike Stroustrup, he has little interest in any balanced discussion on the subject. He's just out to prove the other side wrong — where "wrong" often means "not agreeing with him" — and perhaps, the cynic in me suspects, to make a reputation for himself in the process.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"The Design and Evolution of C++" by Stroustrup is a must-read if you are interested in why C++ is the way it is.
After reading it, I really hated C++. It's the classic example of a project that gets ruined by too many people working on it, all with their own goals, and the book tells you exactly why this happened. C++ now is a hideously complex monstrosity that is popular because it is all things to all people, not because it is a good language.
Anyway, if you disagree with me, have a look at the book. It is a testament to Stroustrup's objectivity that I came to the conclusion I did, and that you may come to the exact opposite conclusion as me after reading it.
And I suppose your shop used to say "COM only", and now says "ugh, COM, who'd want to code those things up". You seem to have swallowed the Microsoft marketing man's sales spiel wholesale.
When you find out how slow some parts of .NET is (eg DB access), or how much memory it uses when you don't want it to, or how to find the object you expected to be GCd but hasn't been.. then you'll think about writing a chunk of your code in old C++.
MS did do a lot of work (pretty poor IMHO though) with C++/CLI to get some interop going between C++ and C#/VB. Poor because of the somewhat contrived bodges to the language they put in that they could have hidden behind the compiler, and also because there isn't any real interop with old unmanaged C++ except by wrapping it with a managed dll (or recompiling with the /clr flag set). Its also a poor implementation - eg STL/CLR is a lot slower than the .NET containers surprisingly.
25 years later there's still not a !@#^%^&$ single compiler that implements the entire language correctly. We're all waiting for Godot...
"Not an actor, but he plays one on TV."
Well, there's no doubt in my mind that C++ is a language design tour de force. The question is whether its design objectives are the right ones.
They were probably the right objectives for the place (Bell Labs) and time (1979) it was conceived.
At the time, computers were inconceivably slow by today's standards. I worked at a small developer that had a very nice AT&T 3B2-400, which had a WE32000 microprocessor, which probably ran at about 10-15MHz; a half dozen programmers shared it.
As for the place, well, it was crawling with C programmers and C libraries, doing rather complex and important systems programming. Compatibility with C and proven C libraries would have been a huge thing.
So, an efficient, object oriented version of C was probably exactly what was needed.
I think that if there was any fault, it was the attempt to meet the goals of efficiency and compatibility with a language that implemented everything that (at the time was thought to be) necessary for programming in an object oriented style. Multiple inheritance carries too much baggage when all you want to do is to guarantee objects have a certain interface. Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion. In situations where you need a special purpose language, it's probably better just to create one.
Still, that's hindsight. If you really understand all the things Stroustrup was trying to do, C++ is quite awe inspiring.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion.
.add(), .subtract(), .multiply(), etc. Once I transliterated a piece of C++ code I had wrote for him and it consumed three times the space and was much less readable due to the nesting of the member functions... being able to use natural math symbols and natural parenthesis makes the math so much more readable, and when 90% of your code is math, you come to appreciate it. I wouldn't have it any other way, at this point.
I write math codes for fun and for a living. I have this discussion on an infrequent basis with a Java buddy of mine. Now granted I'm a dumb mechanical engineer and he's a smart CS major, but when I need some custom math classes that aren't provided by the language (tensors, vectors, Jacobians, Quaternions, etc.) and evaluating long math expressions, it is so much easier to view it using the native math symbols than to nest it all in member functions
Anyone trying to defend C++ as a language should read this. And I speak as a programmer who has used C++ since cfront 1.0 was released to the world.
Useful, yes. Pragmatic, maybe. Design heavily rationalized ex post facto by its creator and its proponents, most certainly. But a well-designed programming language, it is not.
That is all.
On the other hand, that's not the only natural way to handle the situation you are talking about. Another way is to create a new language. Altogether, I'd rather do the kind of work you're talking about in Matlab or Octave.
I write code for clusters, now specifically CFD. Lots of math, lots of parallel processing. Matlab and Octave isn't gonna cut it, and you really desire the close to the metal aspects of c++.
It may be a narrow range, but there's a lot of people in this narrow range. Specifically, (mechanical/aerospace/etc.) engineers. C++ isn't sexy like Java or Python, but we do a lot of things you just can't do in Python, and can't do fast in Java.
Good book, but I don't see how some minor nuances translate to insurmountable design flaws. It's true that proper use of C++ requires a level of expertise beyond what's required for many other languages. IMHO, that just makes real C++ programmers more valuable.
Basically when you have rules you ought to (or "must" unless you want magical bugs) follow that are not enforced by the compiler, the language is flawed. Like when you oveload new but not delete and thus have incompatible memory management. Or you return a reference to a method-local (auto) string object.
It does however give rise to a market for code analysis tools that checks all the stuff the compiler will let you get away with.
But you can save the cost of these tools (or the alternative manual hunt for bugs) by using more modern and productive languages like Java or Ruby, leaving C++ for operating systems and games. And the latter is moving into other lanbguages as well, i.e. Microsofts push for C# in game development, and the widespread use of Python in e.g. EVE Online, ToonTown, Civ IV and other games.
His answer was along the lines of: "Oh, I never use a debugger. If something's not working right I just think about it...maybe I'll add a printf once in a while if I need to check something."
Now you know why utterly un-debuggable features like templates went into the language...
The people using C++ for engineering, mathematical, and scientific applications may be a minority, but not a tiny minority. No one has to deal with operator overloading if it is not applicable to their application. If a developer is too immature to recognize when a feature is a bad choice, then operator overloading is the least of his problems.