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
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.
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.
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."
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
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.
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.