Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming IT Technology

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.
This discussion has been archived. No new comments can be posted.

C++ Creator Confident About Its Future

Comments Filter:
  • by Slow Smurf ( 839532 ) on Saturday April 23, 2005 @01:12PM (#12323400)
    It went from a non object oriented language to an object oriented one, seems like creating to me.

    (though yes, you can of course use OO in C, it just sucks)
  • by 0x461FAB0BD7D2 ( 812236 ) on Saturday April 23, 2005 @01:16PM (#12323429) Journal
    it seems that with corporate support, Java and .NET technologies, as well as Perl, PHP and Python are the major languages for the future, not C++.

    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 .NET may be the future for enterprise software, developers should learn C/C++ first, and not Java, as those who can program effectively in C and/or C++ tend to code better in Java and .NET, while the reverse is not true.
  • C++: too complex (Score:3, Insightful)

    by Anonymous Coward on Saturday April 23, 2005 @01:20PM (#12323458)
    I never saw the point of C++.

    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.
  • by Anonymous Coward on Saturday April 23, 2005 @01:31PM (#12323521)
    You can not match the cleaniness and performance of C++ in regular C. To do the same things you do in C++ in C while maintaining the same performance looks ugly and complex. C just doesn't have enough functionality.

    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.
  • by FidelCatsro ( 861135 ) <(moc.liamg) (ta) (orstacledif)> on Saturday April 23, 2005 @01:47PM (#12323631) Journal
    You dont hammer a nail with a screwdriver , and you dont program an OS in Java.
    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
  • by Chris_Jefferson ( 581445 ) on Saturday April 23, 2005 @01:57PM (#12323697) Homepage
    bar effective string-handling

    out of interest, what's wrong with std::string?

  • by renehollan ( 138013 ) <rhollan@@@clearwire...net> on Saturday April 23, 2005 @02:07PM (#12323766) Homepage Journal
    I've coded in various assembly languages, scripting languages (though I forget Perl as fast as I decide that it's appropriate for some piece of glue and am constant relearning it), C, C++, C#, and yes, even COBOL in the dim past (using COBOL to provide indexed file support to Pascal applications via COMPASS trampolines on an old Cyber 835 running NOS was, well, a scizophrenic programming experience). I tend to like the richness of C++.

    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

  • by the eric conspiracy ( 20178 ) on Saturday April 23, 2005 @02:24PM (#12323862)
    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.

    . 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.

  • by Lally Singh ( 3427 ) on Saturday April 23, 2005 @02:50PM (#12324018) Journal
    It's an actual C++ feature. 90% of the people on this site that say they know C++ know C with classes.
  • by SunFan ( 845761 ) on Saturday April 23, 2005 @03:03PM (#12324098)

    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)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Saturday April 23, 2005 @03:07PM (#12324118)
    It is so bad that it took a decade just to get compilers that worked properly
    The C++ Standard wasn't finalized until 1998. We're seven years out from the Standard, and we've had good compilers for more than a couple of years now. GCC 3.0 is where I draw the line for "good C++ compilers", but Intel and other firms had good C++ compilers for a similarly long time.
    But C++ is an abomination--
    Most C++ enthusiasts, myself included, will agree with you. In some ways, C++ is a lot like Perl. Larry Wall said about Perl, "The language is such a mess because the problem space is such a mess." The same applies to C++.
    I can't imagine why it survives at all.
    If you can't imagine why it survives at all, that strongly suggests you've never bothered to learn why it's survived.
    no consistency of design
    You've clearly never read the C++ standard, where one design goal guides all of the C++ specification: "you don't pay for what you don't use".

    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.
  • by deian ( 736923 ) on Saturday April 23, 2005 @03:21PM (#12324180) Homepage Journal
    I'v been coding in Perl, Java, C and C++ for the past few years and although I prefer using perl and bash I must say that I've learned to think like a programmer having learned C++ first.

    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) ,C++ should be taught before Java.

    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.
  • by Jordy ( 440 ) * <{jordan} {at} {snocap.com}> on Saturday April 23, 2005 @04:14PM (#12324475) Homepage
    You know, you don't have to use a C++ GUI library when writing a C++ application.

    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."
  • by aCapitalist ( 552761 ) on Saturday April 23, 2005 @04:24PM (#12324534)
    ..., and you dont program an OS in Java.
    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++.
  • by mattgreen ( 701203 ) on Saturday April 23, 2005 @04:38PM (#12324606)
    C++ takes quite a bit of flak on here, mostly because it doesn't try to be a 'pure' language. It is obvious that people don't understand it by the comments. (Then again, if people only talked about what they understood, the net would be a very quiet place.)

    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.
  • by Anonymous Brave Guy ( 457657 ) on Saturday April 23, 2005 @05:16PM (#12324822)
    The ideal way of doing things is to write as much as you can in the scripting language. This is almost always faster and more efficient in terms of programmer time. Then, you go back and redo the speed critical bits and pieces in C or C++.

    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.

  • I think that moving to Java is a terrible idea in too, but it has a lot more to do with the teaching than the actual language itself.

    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.
  • by Anonymous Brave Guy ( 457657 ) on Saturday April 23, 2005 @09:29PM (#12326194)
    I just don't think there are _any_ good solutions for writing large, portable, comprehensible, etc. programs.

    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)

    by neonstz ( 79215 ) * on Saturday April 23, 2005 @09:43PM (#12326263) Homepage
    ...a good standardized classlib which covers all important application scope aspects

    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.

    ... a language which is actually usable without having to fight with it for years before being able to master it to a certain degree

    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.

  • by Latent Heat ( 558884 ) on Sunday April 24, 2005 @11:43AM (#12329164)
    You have gotten a lot of responses, some of them diplomatic, others unnecessarily blunt, telling you that you don't know what you are doing if your C++ compile times are that long, and suggesting tweaks -- better make files, pre-compiled headers.

    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.

"Life begins when you can spend your spare time programming instead of watching television." -- Cal Keegan

Working...