C++ Creator Confident About Its Future 241
bonch writes "Bjarne Stroustrup is confident about the future of C++. He says there is a backlash against new languages like Java and C#, and that developers are returning to C++." From the article: "He claimed the main reason why people are not aware of this is because C++ doesn't have a 'propaganda campaign.' Sun Microsystems has touted the use of Java in the Mars Rover program, for example, but Stroustrup asserts that C++ was also used.
Re: creator of the C++ programming language (Score:2, Insightful)
(though yes, you can of course use OO in C, it just sucks)
While it would be nice... (Score:5, Insightful)
Apart from PHP and Perl, the above languages are usually very strict in their object-oriented ways, and thus prevent loose syntax and clumsy errors. But this nannying produces only poorer developers who rely on the language rather than their own abilities to code effectively.
A return to C++ would be nice, especially in educational institutions, as it provides all the necessities of modern languages, bar effective string-handling, while maintaining the simplicity of older languages.
While Java and
C++: too complex (Score:3, Insightful)
I've been programming a while. Familiar with Lisp, Smalltalk, etc. My first "favorite" language was C, which had a certain simplicity that appealed to me. I also liked Objective C.
When I first saw C++ it seemed complicated and half-baked. Objective C was SO much nicer. And one C++ program would work with one compiler, but not another. The language was in a state of flux apparently. So I ignored it, thinking it would be finished later.
By the time I looked at it again, computers were fast enough so that "scripting" languages like Python were practical for big projects, and elegant enough to write good programs in. C++ was still a gigantic clunky mess. I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused. And any language that "mangles" things should be avoided I think.
Also Java looked like "what C++ should've been".
And now the programming world seems to be returning to a desire for simplicity, elegance, "Agility", and C++ just doesn't cut it. My favorite language today for practical work is Ruby, with the occasional C extension.
So, to me, C++ is an obsolete language.
Re:C++: too complex (Score:4, Insightful)
Ruby is slow even for scripting languages. It's fine for many things, but if you need performance Ruby doesn't cut it. And if you really need performance no scripting can cut it and you gotta use something better.
Nothing can equal the power along with performance that C++ gives you. It's not perfect and has some serious issues, but it's the best we have in terms of performance combined with power.
Re:While it would be nice... (Score:3, Insightful)
C++ fills a rather difrent void and there is place for all , it really depends what you want. Right tool for the job as always applys
Re:While it would be nice... (Score:4, Insightful)
out of interest, what's wrong with std::string?
I've always liked C++ (Score:5, Insightful)
However, it's a double-edged sword. It has been said that C lets you shoot yourself in the foot. C++ provides a dozen ways to shoot yourself in both feet and your own back, simultaneously. Be carefull.
Many have tried to design languages to protect the programmer from themselves, i.e. by providing native garbage collection, disallowing bald pointers, etc. However, this is short-sighted. It presumes what is "hard" and prevents the skilled programmer from replacing the default implementation. C++ new and delete member functions provide no-fuss custom memory management... and probably account for probably half of those ways of shooting one's self in both feet and back.
A language that is complete in the sense of permitting the coding of fundemental facilities is seductive. It provides an assurance that one can implement "low-level" stuff like memory management, or even the bulk of an O/S kernel in it. The lack of I/O facilities in C, for example, is an intentional feature, and not an oversight. Never have to learn another language again.
Other languages may provide the convenience of built-in capabilities that are useful for a particular task at hand: awk, perl, and the rash of modern scripting languages come to mind. When the shoe fits, the adaptable programmer will take the path of least resistance. Languages like Java and C# attempt to bridge the general-purpose languages with the protection and features offered by application-specific ones, the latter via extensive run-time libraries (.NET, anyone?). They tend to return to the pseudo-compiled small-interpreter model to provide hardware portability.
The problem is, that one has do do things the C# "way", or the .NET "way", or the Java "way". Multiple inheritance? Oooh, it's so hard to implement right, and can be so confusing, and, admitedly can be expensive at run-time, so we'll not provide it. Mixin becomes a hack, with language keyword support. Over time, syntactic sugar in the language provides clever support for things like iterators, but binds language features to what should be artbitrary types (Lists are special in C#, for example).
Well, I want it all.
A programming language that will let me shoot myself in the foot any way from Sunday if I dare to try... but, with the flexibility to let me say, "Nope. No bald pointers here." Segregation of programmable expressiveness by program, not language, design.
A programming language that is mutable, so I can invent my own brand of syntactic sugar, and the support to let me quickly find out what mutations a particular piece of code uses.
A programming language that lets me choose when to evaluate things. Do I want this figured out at compile time? Link time? Load time? Run time? Sorry, C++ templates, though Turing-complete are about as maintainable as APL, if one uses them for anythng clever.
It's too bad Mary2 never caught on.
Many will argue that mutable languages result in unmaintainable code: which mutation is in force? I would counter that programs written in non-mutable languages are equally unmaintainable if one does not understand the design of the application. Sure, one can see the "trees", but not the forest: I know x = a + b adds a and b to yield x, but what is that for? The effort to undestand what mutations are in effect is likely similar to the effort to understand an application's design. Except, one has the advantage of a known meta-syntax for expressing the mutatations, instead of having to rely on a design document (which may not exist), likely poorly written or out of date
Re:While it would be nice... (Score:3, Insightful)
. You may complain about Java etc. being inefficient or coddling developers, but the design of C++ is strictly a case of bolting object orientation onto a procedural language in a very crude manner, then throwing in the kitchen sink just so that it has feature xyz. It collapses of it's own weight. C was/is fine with it's minimalist approach and economy of expression. Java and other GC languages have thei place because by handling GC they markedly improve programmer productivity.
But C++ is an abomination - a siamese twin floor wax/desert topping that should have been seperated into C and a real OO language years ago. I can't imagine why it survives at all. It is like one of those Cadillacs from the 60's with the giant tail fins and 400 pounds of chrome, and no consistency of design. It is so bad that it took a decade just to get compilers that worked properly - and from what I've seen there are still a lot of C++ compilers out there that fail to completely implement the language.
Re:While it would be nice... (Score:5, Insightful)
Re:To those who have not programmed in C++ enough. (Score:3, Insightful)
With well-organized header files and a little documentation, I've had no problems with C up to 100K lines. The main advantage, IMO, is that C is just so damn simple to "execute" in my mind, and it is very intuitive to step through in a debugger. The only real catch for me is tracking down memory leaks at times.
Now, for programs with millions of LOC, I don't think any language will be easier than another, just because the program's own complexity overwhelms everything else. Just ask people how quickly they can get up to speed on OO.org, KDE, Mozilla, or GNOME (they all suck for casual developers).
Nice troll. (Score:5, Insightful)
You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.
High School's should teach C++ (Score:5, Insightful)
I also eneded up taking a C++ course in High School, and I found that many of my classmates started to think and analyze problems differently. A year later the school changed from C++ to Java ( because the CollegeBoard changed it's CS exams to Java). I also took that class and I noticed that the kids that only took Java, even after completing the course did not learn much - and especially not to think like programmers. I think that this is most likely because Java has so many libraries within that the kids never actually learn what occurs in the "back end." Many fail to understand what a string is, and the majority did not understand algorithms at all, I dont want to mention efficency. Although Java is probablly used more widely, I think that for beginners to learn to think like programmers it would be better to learn a language from which they can learn the basics behind programming, and although I would suggest PASCAL (better for learning algorithms)
Learning DSA with Java is a bit funny, how is having a garbage collector efficent and how will that inspire programmers to write more cautius and efficent code?
Just my opinion, I'd like to learn more.
Re:The reason I don't use it (Score:4, Insightful)
Seems sort of silly to state that C++ doesn't have a good set of libraries when you can use any C library you wish. I do it all the time. There is no reason to create a C++ resolver library when a simple one exists in C already.
C++ has a very simple philosophy, you don't pay for what you don't use. You can write C and occassionally use std::string if you want to. Nothing stops you from doing it. There is no rule that says, "thou shalt use operator overloading."
Re:While it would be nice... (Score:3, Insightful)
C++ fills a rather difrent void and there is place for all
How many operating systems are coded in C++? I know a lot that have been coded in C, but none that have been coded in C++.
Closed-mindedness abounds (Score:4, Insightful)
News flash: most software that I've seen and written benefits from multiple paradigms: procedural for basic algorithm implementation, OOP for the architecture, and generic programming as glue code (generic programming annihilates OOP in terms of code reuse, and you typically don't pay a performance penalty for it.) There are other paradigms, but I don't have enough experience to comment on the efficiency of them. C++ is one of the few languages that gives the aforementioned paradigms a presence and trusts the programmer to choose. You may think this is 'bloated,' but nothing is further from the truth: the overall mantra of C++ is, "you only pay for what you use."
You can bitch all you want about the importance of language purity and point to languages like Smalltalk or Java as an example of how software should be coded. I'll ask you to point me to popular desktop software that is written in these languages. C++ is the archetype of a hardcore language - a huge learning curve, but insanely powerful in the right hands. It is also really dangerous in the wrong hands.
Like operating systems, all programming languages suck in some way. Its up to you to choose the least sucky one for the problem at hand. I enjoy writing native, minimal dependency desktop applications in a language that has excellent tool support, can interface directly with OS APIs, and doesn't talk down to me. C++ fits the bill most closely, but I've been told I'd like O'Caml as well.
C++ isn't going anywhere. The fact that so many people don't understand it or the place that it occupies only strengthens my resume.
Multi-language approaches (Score:3, Insightful)
I've heard that a lot, and certainly the argument has merit.
Where it sometimes breaks down, IMHO, is that learning a new language isn't free. It's a myth that any good programmer can learn a new language in a week. Sure, they can learn the basic syntax, and if they're familiar with the particular paradigms they're using (by which I mean OOP, functional programming, whatever) then they'll be able to apply those principles fairly readily. But there's a world of difference between that and the kind of clean, idiomatic, easily maintainable code than a good programmer with a lot of experience in the specific language(s) he's using would write.
I predict that this is going to be one of the bigger factors holding back $SCRIPTING_LANGUAGE from wider usage for a long time. There are simply too many almost isomorphic scripting languages with a significant, but still small, user base, and while they offer similar advantages, you can't just switch a whole dev team from one to another for the reason above.
I think this is also a big reason C++ remains popular, particularly with stronger programmers who make the effort to learn its idioms, who for some probably related reason rarely seem to encounter all these dreadful weaknesses C++ is supposed to have... In a nutshell, C++ is a single language with sufficient tools to work effectively with both low-level details and high-level designs, and perhaps a strong programmer with such a tool will be more effective than a programmer with two more suitable tools, but only moderate skill with either.
Re:Some backlash in academics as well.. (Score:5, Insightful)
Java is a fine language. I've done a lot of cool stuff in Java. Out of the box, it has libraries to handle multithreading and all sorts of neat stuff.
The problem is that when you don't have to worry about things like memory management, you lose a huge part of your education. You don't think about things in terms of the kind of resources that you might use, you just do it.
In a way, it may be possible to go to a purer kind of programming with Java, needing only to worry about the algorithmic complexity of the method that you're coding. In practice, however, I've seen nothing but sloppy work out of people trained from the start using Java.
I coded in at least 6 different languages through my degree, and I did most of my work in C, not C++. I believe that when you start, you should start close to the machine, not as far away from it as possible. Start with assembly - the programs don't have to be big - and work your way up. Java is the last step you should take, after you understand what it's doing under the hood, and how to mitigate the overhead that those sorts of things will incur.
Re:To those who have not programmed in C++ enough. (Score:3, Insightful)
Sad, but almost certainly true.
As I've said in these parts before, C++ should have been superceded for all areas of programming a very long time ago. The fact that it hasn't is a pretty damning indictment of the software development community as a whole, a reflection of how little "new" languages like Java or C# have really added, and an insight into how productive many theoretically sounder languages beloved of academics are out in the real world.
Re:Id rather (Score:3, Insightful)
Eh. You have no idea what C++ is used for. Programming isn't just writing nice little programs for desktop computers. C++ is used in everything from tiny microcontrollers to large clusters. Good luck writing a classlib which covers that.
You mention KDE/Qt as examples on APIs that are good. I use Qt at work and I really like it. However, Qt covers just one (or a few) uses of C++, regular applications which run on standard desktop computers/handhelds (or servers), usually with a GUI. Qt would've been no use for me when I used C++ for coding for the Gameboy Advance.
Yes, mastering C++ is hard. So is mastering Java/C#. I've seen a lot of really crappy C++ code, but I've also seen equally bad java-code. A computer language won't help you write better code. It may not crash and burn like a C/C++ pointer error, but an uncaught exception or excessive object creation in innerloops in java is just as bad.
(As a side note. Bjarne was talking about the future of C++ last week, and one of the things he addressed was that C++ have become a bit too "expert friendly". They're addressing this in the next C++ standard, but don't expect anything revolutionary.
(A lot of times) C++ programmers miss the point (Score:3, Insightful)
Well, you and your colleagues could bone up on the skills to compile large C++ programs, but you could also hire some people who are experts at IBM OS/360 JCL while you are at it.
Anyone here remember JCL? The idea was that you had a "separation of concerns" between abstract operations on files (Open, Read, Write, Seek, Close) and a whole panoply of file-specific parameters (disk, tape, random-access, sequential, block size, buffer sizes), and that you only had the abstract parts in actual compiled code while the connections between the abstract parts and the OS went into a kind of shell script that specified these connections. Then these guys in New Jersey came up with this Unix thingy which didn't have any of this stuff. Unix "solved" the problem JCL was addressing by not having that problem in the first place.
My point is not that Java is "better" than C++ -- there are many criteria in what language is suitable for what kind of problems -- but that C++ is so ancient history even within its own problem domain. Make files? Pre-compiled headers? The problems those features were meant to solve were obviated by Wirth and his gang back in the Modula 2 days just like Unix made JCL go away.
The suggestions you have rolling in to speed up your C++ compiles are all well and good, but the fact that people are calling you stupid. How about another analogy. The F-104 has some bad user-interface issues along with slim stall margins on landings. It killed a lot of pilots in its day, and the pilots who survived would all say that the pilots who didn't lacked "the Right Stuff", but I don't think there are any Air Force planes these days that are quite so unforgiving.