Slashdot Mirror
The Future of C++ As Seen By Its Creator
holden writes "In a rare public talk, C++ creator Dr. Bjarne Stroustrup discusses his ideal in programming languages, as well how he sees the next version (and beyond) of C++ developing. He explains the general selection criteria used for adding new features, some of the legacy of C++, and many other interesting topics. Especially interesting is during the Q&A he explains his views of the embrace and extend mentality some implementations, such as VC++, have taken."
Good afternoon everybody, I would like to start by including iostream.h into the discussion.
After this we can get onto the main proceedings which might or might not return anything.
We move to the future by emitting a string of "Hello world" before returning zero.
This is the end of the discussion I hope it was informative.
liqbase
Video or audio just for the sake of being flashy is a dumb idea and I usually won't watch or listen. If I want audio and video I'll devote my full attention to my TV feed. Otherwise when I'm accessing information on the Internet I want text. I can read it far faster than someone speaks on a video interview for one thing, and for another text lends itself far better to (human)multitasking than video or audio does.
Is that they have given 95% of the development time toward managed languages.
.NET has advanced from 2.0 to 3.5 with huge changes like WPF, WCF, LINQ, etc. They have all but forgotten C++.
If you look at the new Visual Studio 2008 - in the three years since 2005 was released, what does Orcas have for C/C++? Still no C99, with open admission that there are no plans to support it. No TR1 for C++. No significant compiler changes. Intellisense is still slow and quite easily stops working all together. Still no assembly support in the 64-bit compiler, missing intrinsic functions for important instructions such as CMPXCHG16B.
What we get is a newer bundled Windows SDK (which you can download NOW), updated MFC libraries (yuck), and a few new options for Vista compatibility.
In three years,
That ruined the joke for me. Like Stroustrup would ever include the legacy non-namespaced header!
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
exception: slashdot editors.
Do you even lift?
These aren't the 'roids you're looking for.
Recently, I've just started getting into C++, and I can't understand why so many people hate the language with such a passion. The thing is, if you need/want to write your program in a compiled language with plenty of library support, then aside from C, what options are there? I'm not trying to start a flamewar, but I figure if I want to say use C (or other C++) libraries and a compiled language then I feel C++ is much better option than C. One very smart and experienced C programmer I know hates C++ with a passion complaining that "it's too complex" and just rejecting it outright.
I haven't yet written (or debugged) any large programs in C++, so that could be why I'm still enthusastic. Perhaps after some time with the language I might see what everyone is so worked up about.
I'm reading through "Effective C++" by Scott Meyers, and although the language seems like it has its warts and complexity, it also offers a great deal of power and is a hell of a lot more fun to program in than C because you get the abstraction support of objects, namespaces etc. Streams - awsome. Shared (reference counting) pointers - awsome. Less need for the preprocessor - awsome. And the standard library (plus Boost too) is so vast... containers, algorithms, it's all there.
Python is still my favourite general-purpose language, but if I need something compiled, then I don't see what is so bad about C++. Sure, Objective-C is a far better approach to the "lets-make-a-better-C" idea, but I'm not sure how to use it (and the standard library) outside of OSX or GNUStep.
A marriage is always made up of two people who are prepared to swear that only the other one snores.
Here ya go, buddy.
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 diculously 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.
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: Not in the slightest. Trouble is, most companies hush-up all their major blunders, and explaining a $30 million loss to the shareholders would have been difficult. Give them their due, though, they made it work in the end.
Interviewer: They did? Well, there you are then, it proves O-O works.
Stroustrup: Well, almost. The executable was so huge, it took five minutes to load, on an HP workstation, with 128MB of RAM. Then it ran like treacle. Actually, I thought this would be a majo
8 of 13 people found this answer helpful. Did you?
C++ is far too complex yes. But there is nothing that can really replace it. A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building?
The thing is, most development projects that use C++ today don't need all of that.
C++ is a fine, pragmatic tool, and I have great admiration for Stroustrup's ability to build such a useful thing. C++ is also a powerful systems programming tool.
But C++ is not a good language for most application development, which is what a great deal of code written in it really is. I think there are several separate but somewhat related reasons for this.
One is the safety argument. Most people simply don't need the flexibility/footshootability [delete as applicable] of C++. You need only look at the much-hyped field of garbage collection to see that (a) many professional developers find this one feature useful that they regard Java as superior to C++ for this reason alone, (b) many more professional developers have no clue about the overheads involved (which are almost zero for typical applications using modern approaches to GC implementation), and most importantly (c) a great many developers using languages without GC make mistakes that developers using languages with GC wouldn't. Similar arguments apply to other routine problems, such as pointers/NULL.
The second is the expressive power argument. Life is too short to be using programming languages with primitive, error-prone control flow constructs, functions that aren't first-order entities, no syntactic support for common data structures, crude macros, header files, etc.
Third we have the standard library argument. Yes, yes, you can get a C++ library for almost anything. That's not the point. The key word is "standard". Take a look at the huge practical success of Java and Perl, and tell me the vast Java standard library and CPAN have nothing to do with them. Sure, C++'s standard library is, technically, of a higher quality than most. But it still has stupid flaws (string support and IO streams are both fundamentally broken, for example). More seriously, it has stupid gaps. In the 21st century, it's hard to seriously advocate application development in a language with no standardised support for user interfaces, networking, concurrency, file systems, etc. No, I'm not going to spend days trying to find the right non-standard library for me. Non-standard libraries are for solving significant problems, where the difficulty and scope make it worth investing the time to find and hook in someone else's code. They're not for trivia that everyone uses all the time.
And finally, we have the tools argument. Working with header files sucks, and while just about everyone else is playing with their funky, auto-refactoring, navigation supporting editors, what do we have? VC++ (where refactoring still isn't available in native C++) and Eclipse (which is C++ forced into a Java-like IDE)?
The really scary thing is that reality bites now. It's not like I'm the first person to identify these practical flaws with using C++ for application development. It's not like other people haven't developed languages and tools with all these improvements already. And yet C++ continues to be one of the most important application programming languages today. Why?
Momentum. That's why. Building a new programming language with a syntax that doesn't look like C is asking for trouble; just look at the arguments Python sees over whitespace. (Curiously, I've never seen such complaints made about Haskell. Perhaps this shows a difference between the insight of your average professional programmer vs. your average language geek academic?) More to the point, trying to advocate a new programming language for industrial application development that isn't some form of block-structured, OO-based clone is asking for trouble.
I'm hopeful that over the next few years, as hardwar
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
C++ has many problems. Some, like "an array is a pointer", it inherited from C. Some were mistakes in the original design that were later fixed, like unchecked downcasts, "this" as a pointer rather than a reference, and the lack of generics. And some are there because Strostrup is in denial about the problems, like the fact that the language gives no help with either thread or memory management.
Memory management remains the biggest problem. The fundamental problem is that C and C++ require the programmer to obsess on who owns what, while providing zero assistance in managing that information.There are ways out of this, involving syntax and compiler support for owning and non-owning pointers. But instead, attempts have been made to paper over the problem with templates. This never quite works, because for some things you still need a raw pointer, which breaks the abstraction. The history of auto_ptr (up to standard revision #4 now, I think) makes this clear.
Bolting on a garbage collector doesn't help much in a language with destructors; see the mess in Microsoft's "managed C++". If you're going to go with a garbage collected approach, it's better to go to a language designed for it, like Java.
Most of the standards effort is going into template features that few will use and fewer still will use well. Trying to use the template expansion engine as a general purpose macro system is a terrible idea for production code. But it has a big fan club on the standards committee. Worse, the C++ commitee does very little to improve language safety and reliability. Which is why we still have buffer overflows in C++ code, fifteen years in.
Incidentally, none of this has anything to do with C++ being compiled directly to machine code. There have been safer compilable languages usable for system-level programming. Modula 3 was probably as good as it got. But that language died when DEC went under. It's possible to hard-compile Java; there's a version of GCC for that, and it's getting some interest in the embedded community. The problem could be fixed. But it won't be, because the people responsible are in denial.
COBOL is already a joke.