Slashdot Mirror
C++ Creator Confident About Its Future
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.
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++.
.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.
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
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.
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
You could've hired me.
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.
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.
,C++ should be taught before Java.
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.
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.