January 12, 2007
MIT's Technology Review recently interviewed Bjarne Stroustrup in a two-part article (part one, part two). You may know Bjarne as the inventor of the C++ programming language. Indeed, he even maintains a comprehensive C++ FAQ that answers every imaginable C++ question.
Here are a few select quotes from the interview that I found notable:
C++ has indeed become too "expert friendly" at a time where the degree of effective formal education of the average software developer has declined. However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts. There has to be languages for those experts to use-- and C++ is one of those languages.
What I did do was to design C++ as first of all a systems programming language: I wanted to be able to write device drivers, embedded systems, and other code that needed to use hardware directly. Next, I wanted C++ to be a good language for designing tools. That required flexibility and performance, but also the ability to express elegant interfaces. My view was that to do higher-level stuff, to build complete applications, you first needed to buy, build, or borrow libraries providing appropriate abstractions. Often, when people have trouble with C++, the real problem is that they don't have appropriate libraries--or that they can't find the libraries that are available.
Other languages have tried to more directly support high-level applications. That works, but often that support comes at the cost of specialization. Personally, I wouldn't design a tool that could do only what I wanted--I aim for generality.
I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
In the FAQ and the interview, Bjarne comes off as a little defensive about C++ and its role in the history of computer languages. Maybe that's because the importance of C++ has diminished over time, principally for two reasons:
- C++ is fast but unforgiving. It was an appropriate solution for an era of limited computing resources. But we've long since left that behind; we live in an era of abundance. We have more computer power than we possibly know what to do with on the desktop. Even the naive solutions for most computing problems are "fast enough" these days. Computers get faster every day, but programmers' brains, sadly, do not. It'd be a waste not to trade some of that abundant raw power to make things easier on us. It's time to evolve up the one trillion dollar programming pyramid.
- C++ is designed for any possible programming task, from the lowest level to the highest. It makes sense to use C++ to write operating system kernels and device drivers. But when was the last time you used C++ to write a line of business app or website? C++ is perhaps the ultimate generalist language. Because it can do all these things, it's complicated and dangerous. Other languages don't try to span the entire range of low-level to high-level programming tasks; they simplify to attack a specific high-level problem domain.
C++ is a key historic milestone in the evolution of computer languages. There will always be a place in a programmer's toolbox for C++, but I'd argue that it's an increasingly a niche language for a very specific subset of programming tasks. The most important question to ask about any language these days isn't how fast it is, or how general it is, but how well does it protect you from yourself? Stroustrup has a great quote that says it all:
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.
Posted by Jeff Atwood
Haha, you obviously have no idea how a compiler works and what the difference is between a compiler, an intepreter, a bytecode and a JIT compiler.
Anyway as someone way above stated very clearly C will always be used for low level stuff, kernel and drivers. C and not C++ which has nothing to do with C whatsoever. Furthermore if you want speed or small code you use C, not C++ and all the mess it generates with classes and stuff.
FYI -- there is now post-tension concrete that actually makes concrete harder because it is compacted. also, there are different grades of concrete, the best using ash that strengthens concrete over time. it just goes to show the old saying is true: garbage in, garbage out.
C and C++ will always have their place for writing core libraries. and i'm a lot more comforatble managing my own memory (until i get Alzheimer's) than some new-college grad that's never heard of pointers. Even MS developers don't trust the garbage collection in the .NET languages. (i can't find the post right now...)
"But when was the last time you used C++ to write a line of business app or website?"
Hmmm. I guess that would have been last Friday, January 12 2007, when I was writing code for flight software application at a major aerospace corporation. For some odd reason, we aren't converting our insanely huge C/C++/Fortran codebase into Java, D, Ruby on Rails, Python, Perl, or whatever the current flavor-of-the-month language is...
I've been coding for about 20 years, in all sorts of languages. Assembler, Java, Smalltalk, JCL, REXX, C, C++, C#, Shell, Pascal, Perl, PHP, Ruby, TCL, Eiffel, Maple, Mathematica, Gauss...god knows what else, even VHDL's for FPGA's. Let me say that C++ is pretty great, and infact is what I've chosen to use for a number of new projects.
Here are some comments on assumptions on points above:
1) Many assume 'higher level language' needs to be 'slower'. That's just not true at all. That said, if it's slow in C++, it's likely your algorithm, while if it's slow in a high level language, it's probably that you're using convenience classes that are poorly suited for your problem domain.
2) It's true that a lot of programmers aren't formally trained anymore. If a programmer can't work out time complexity between a Quick Sort and a Bubble Sort (really basic questions), I don't hire them. Even if they'll be using a high level language. I've seen hundreds of thousands of dollars go up in smoke because programmers honestly didn't understand why the Java ArrayList behaved so poorly when used as a queue, and the queue size grew. Actually, change that: millions lost. High level langauges should be used for their expressive power, not as a crutch for people who shouldn't be programming commercially. It's ilke the comment above, "you don't know when you're hit".
3) Many high level languages are compromising in areas they shouldn't, letting programmers be lazy. If there's one problem with coders in high level languages, is that they don't seem to write much 'error checking' code. If something like VB or C# had Design by Contract built in (like Eiffel has) forced as part of the language, I'd be happier. I do know about Spec#, and other C# DBC extensions. Really, the language should be easy to use, but also do it's bit to enforce some quality.
4) Vista's way slow. I played with it yesterday and I could see delays in the icons on the start menu popping up. It's pretty pathetic. If I were Microsoft, I wouldn't be proud of it.
5) C# is a nice language. I'd rather people learn Smalltalk tho. Squeak is cool.
Only in the last three years have I spent more time with C++, and I'd have to say it's a pretty excellent language. C# is cute too, but it's performance isn't there. I wrote a test system in C, C#, and Ruby the other day. Ruby got 11,000 operations/sec, C# got 34,000 operations/sec, and C++ got 71,000 operations/sec. The C++ code compiled on Windows, Linux, and BSD without any warnings or code changes. It also used the least RAM.
Fast? Portable? CPU and Memory efficient? Do these things matter to anyone?
If you can't handle the power, just steer away from it. Don't badmouth C++ because of your inability to use it correctly.
I don't know, maybe it's just that I don't like to be kept in a little box that protects me from the real world, but I prefer using C++ over all these languages whenever possible. That said, I do think that some languages are more suitable for some tasks.
Citing Bjarne, "Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained." Just go to www.thedailywtf.com and you'll see that most posts come from Java and VB "programmers".
Myself, I'm eagerly waiting for the new C++ standard that will give us more template power and some new library additions (among other cool stuff). Read about it at:
I'm wondering why people seem to think they can optimize code better than a mature optimizing compiler... In general, it's best to let the compiler do the work.
I also keep going back to the last point on the original post: which language best protects against human foibles? My answer would be the language that is the most readable and maintainable (good examples being Ada and Python). Almost all code will be read many more times than it will be written, and any long-lived system ends up with about 10% of the total cost in the development phase, and about 90% of the cost in the maintenance phase. Draw your own conclusions...
That's exactly why I like C# so much. It's just too bad that we are restricted to one single platform by using it :(
One of my first Computer Science instructors told me that anyone who is a solid C++ programmer knows how to program and can pick up any language out there. This has held true since I heard it 10 years ago, with perhaps the only exception being Lisp (my favorite language to play with), which many OO programmers have issues with.
The reason C++ is a good language is because it makes better programmers of us all. From low-level understanding of how the machine works by figuring out how pointers work, to high level understanding of how objects and inheritance work, C++ covers it all. After spend 2 days trying to figure out why your program keeps saying "Segmentation Fault (Core Dump)", you learn/understand the importance of memory/pointer management. Struggling to write a linked list, and then learning about the STL makes you realize how important reusable code is.
Sure C++ is very difficult to learn and understand, but once you do, you have top to bottom knowledge and understanding of how a computer works. For all its faults, C++ should be a language every programmer has in his/her toolkit.
C++ is difficult and for experienced programmers, experience at least with C. You can do whatever you want fast. But it is not for everyone.
Daniel: You can code cross platform with C#, Mono has come on leaps and bounds. You do have to put the extra effort of making sure your code is fully compatible with Mono and that you don’t use anything windows specific. You don't get anything for free ;)
Jeff: I whole-heartedly agree! C++ is a great language for hardware interaction or even for making a component that has a need for the most performance possible, but its power and flexibility means you have to take more control and responsibility over everything. More recent high level languages like C# take some of that power and flexibility away, but with less under your responsibility to directly control your productivity is greatly increased and the language/framework can protect you from many common mistakes.
Strangely, in my feedreader (Newshutch) the whole article references C and not C++...
There is another (than MS) C# compiler in existence:
But alas, whatever the language, there will always be cases of "(accidental) use of the ordnance to hurt yourself".
Some languages protect you more, many protect you less, but incorrect code is always incorrect code.
there's a new language out there released just a couple of weeks ago called "D". It offers performance and flexibility of C++ and high level features like garbage collector. Syntax is very similar to java and c#.
Is it just me or has the bitchiness level on this board has gone up considerably in the new year? Jeff writes an entry on Vista's search feature and everybody and his brother jumps down his throat for being pro-ms.
He runs a post about C++ and it's relationship to newer languages and all the C++ people flip out and kick in condescending overdrive.
"Programmer laziness" is the dumbest phrase I hear on posts these days. The fact is you can get considerably more done in a given amount of time with the "cute" languages like C# and Java than you can with C++ or C. It's easier to recruit or train people in them to maintain the code. If you are writing an application that lends itself to such a language/platform wtf would you not use it?
I don't suppose any of you non-lazy types would bother to go to Ikea when you need a new coffee table. I bet you head out to the woods to chop down some trees and assemble it yourself. Damn you're cool. I'll just sit down with my lazy-self, kick my feet up on my new coffee table and drink a beer while you "real" programmers are off in the woods fighting with bears and chopping down trees (no chainsaws, just axes).
Of course you wouldn't rewrite all your legacy apps in a new language that makes no sense. Writing a whole new business application in C++ when C# or Java would do just as well? Well that's just a waste of time and money.
So C++ was a step in the wrong direction if you want a general-purpose programming language. For most tasks its’ complexity is harmful.
Still, new mainstream-languages like Java and C# adopt the C and C++’ syntax, the type system, and control structures. Maybe it is time to realize that all languages that stems from C are broken?
"One of my first Computer Science instructors told me that anyone who is a solid C++ programmer knows how to program and can pick up any language out there. This has held true since I heard it 10 years ago, with perhaps the only exception being Lisp (my favorite language to play with), which many OO programmers have issues with." --Bill
I'm glad you mentioned this. Maybe it's just me but I don't sense that Bjarne values productivity. If you can do C++, you're going to be able to spit out an web application using Ruby on Rails or ColdFusion in no time. But if you try doing it in C++, chances are one of these non-highly-trained-programmers are probably going to crank something out before the master C++ person. It's almost like he's arguing an experienced plumber should keep welding copper pipes together instead of using those fancy sleeves where they can just quickly crimp together 2 pipes. It's important to know the basics but don't run away from productivity lest you want to be out of work and out of business.
hotdogs: D-1.0 was released couple of weeks ago. D itself lives for dozens of weeks now.
TheGeoff, so you don't agree that there is an increasing number of undereducated programmers, and that this is caused mainly because they are getting accustomed to have important tasks done for them? Read what Bjarne said in the quoted snippet, it's all true.
Like Bill Watts said, competent C++ developers can be competent in other languages quite easily, while it's not true the other way around.
I'm not saying I hate languages like C# (but yeah, I truly dislike Java and VB) but I'd say it's healthy to remain competent in languages like C++. It actually seems they put time to design C#. But if you're into the Managed stuff, I'd recommend getting into C++/CLI.
wow, way to go spreading FUD.
"it's dangerous"? a programming language isn't dangerous. an uneducated programmer is dangerous. if you can't program well in something, either better your skills or stick to something you know.
by the way, is something just really screwed up with your CAPTCHA system, or do i just keep getting "orange"?
To me, C++ is a better choice for most embedded software, excluding UIs. Java and C# are preferable as you get closer to the user and performance becomes less of an issue. At the lower layers, though, there will always be a need for a C++ type language. These components are small in number, but very important still.
I work in the embedded (Linux) world, and the real problem I see is that there is still too much use of plain C: C++ would be a step up, but it hasn't taken off. It will be interesting to see if Mono fares any better.
I think the one fatal flaw of C++ that prevents it from moving forward (in the guise of managed C++ or what have you) is its syntax. No one wants to write a parser for C++, and the toolsets for analyzing and generating C++ code are commensurately lacking.
I am on a legacy application that is C++, and I continue to do new development on it. My team is trying to evolve the app to .NET (you can't beat garbage collection and no memory corruption!) With managed C++ and Microsoft Visual Studio, I feel like the weird aunt that is invited to Thanksgiving out of guilt, and the hosts keep giving me subtle hints that it would be okay if I went home early. I will move to C# as soon as I can not because it has better constructs than C++, but because it has better tools.
Jeff, I think you've settled into a comfort groove where you feel C# has ample speed for your needs. From such a position it is understandable to sneer at C++ for trying harder than it's worth nowadays. But this "abundance" you're seeing is a mirage -- just imagine if every single application you use daily were written in a managed language. Visual Studio, firefox, winamp, Windows Explorer, Microsoft Office. The mental picture would be devastating. It's ok for one program to lag slightly when doing UI; it's a cataclysm when the whole system bends.
C and C++ will always be around, just like cement will be for construction.
The difference is these days we don't need to worry about the cement and we can just get on with building the house.
* DISCLAIMER - Cement may not always be around
It is only dangerous for incompetent programmers, real C++ programmers know there standard library and use reference counting pointers where needed. Having said that, you don't seem to give any points yourself as to why C++ is dangerous, you probably don't even know why Bjarne Stroustrup mentions all these points.
I would like to know what you are trying to achieve with spreading this kind of FUD and miss information? Did you ever use C++? Are you a D-programming language zealot that is insecure about his programming language or something? Or are you just uneducated?
Spoken like a true VB programmer. C++ is a very useful, powerful, and relevant language. No need to bash it because you don't use it.
If you take the shooting analogy further, you would blow the whole guy away if you do it in C#. If a language is deemed "easier" it automatically requires less brains to do the job.
There's nothing wrong with cement (concrete). We've been using it for thousands of years, and it should be good enough for a thousand more. Now just overlook the way it fails in tension, leading to problems with earthquakes and hurricanes, the way it takes lots of hand-built forms and hand-wired rebar, and the terrible insulation properties.
On the other hand, you could deliver a bunch of lightweight panels of carbon fiber/epoxy honeycomb with any old pickup truck, and glue them together at the job site. Maybe it's time for a carbon-fiber programming language, too.
Bjarne's response sounds very sensical. I do not see anything defensive about it. We should be using a wide variety of languages and some, like C++, should exist that aren't dumbed down for casual programmers. And yes, there are still far too many idiot programmers employed these days...even after the tech crash.
The C language was wrongly misused for business applications. C was handy because of the notion of having one source that could be compiled on multiple target machines, yet have near Assembler speed.
Delphi (Object Pascal) became such a hit, and many, many commercial apps are written in it, because it allowed you to do business development quickly with a highly powerful language that could do most of what C or C++ could do, and usually match it's speed. It has very good garbage collection, and it's clear how the Borland engineers who left to go to MS have influenced the MS products we have today.
Borland's internal reorganization aside, Delphi remains the best Win32 dev tool in existence, and a decent .NET dev platform. One which even allows Win32 Delphi apps to be recompiled for .NET, preserving the developer's code base. Something MS did not make available for all the VB and C++ apps that needed to be converted to .NET.
C++ is here to stay, at least for a while; 10 or 15 years at least. There's just too much code already written in C++, especially libraries. Even if we are able to use all those libraries in all other languages, someone has to maintain the libraries.
Forget "D", I really like the "E" programming language:
"E is an object-oriented programming language for secure distributed computing, created by Mark S. Miller and others at Electric Communities in 1997. A concurrency model based on event loops and promises ensures that deadlock can never occur.
"The entire language is designed with secure computing in mind; this is accomplished chiefly by strict adherence to the object-oriented computing model, which in its pure form has properties that support secure computing. The E language and its standard library employ a capability-based design philosophy throughout in order to help programmers build secure software and to enable software components to co-operate even if they don't fully trust each other. In E, object references serve as capabilities, hence capabilities add no computational or conceptual overhead costs. ...
"In E, all values are objects and computation is performed by sending messages to objects. Each object belongs to a vat (analogous to a process). Each vat has a single thread of execution, a stack frame, and an event queue. Distributed programming is just a matter of sending messages to remote objects (objects in other vats). ...
"E has two ways of sending messages: the immediate call and the eventual send. An immediate call is just like a typical function or method call in a non-concurrent language: the sender waits until the receiver finishes and returns a value. An eventual send sends the message while producing a placeholder for the result called a promise. The sender proceeds immediately with the promise. Later, when the receiver finishes and yields a result, the promise resolves to the result. Since only eventual sends are allowed when communicating with remote objects, deadlocks cannot happen. In distributed systems, the promise mechanism also minimizes delays caused by network latency."
Reading the responces is interesting. I may be a hobbyist programmer but I've never understood why I need to consern myself with the dirt and grime of the lower workings just to write an application. As has been mentioned, it's great for low level stuff, it's great for cement, but it really isn't friendly for high level stuff. I read dozens of people saying that if you can't program well in C++ then get better, or you should give up. But tbh, I don't want to need to program well in C++. I can, but for a Win32 application why should I need to worry about the ton of stuff C++ forces me to worry about just to get basic stability? Why can't I concern myself more with ironing out the bugs in my application and making the code I've written to do what I want actualy does what I want rather than worrying about the lower levels? But I'm sure people will still cling to using C++ to program websites.
I'm never going to use E as long as examples show people protecting a 'return' statement with an 'else.' That's why I don't use C anymore--the same idiotic motif shows up in KR. And those guys were supposed to be good programmers. Gaaah!
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."
C# makes it harder still, but when you do, you don't know where your hit.
I don't think it is right to just say that "C++ is fast" without qualifying such a statement. C++ allows you to optimize code at a micro level more than any other language that also has high-level features.
That said, most optimization problems occur at an algorithmic level. In those cases, I find that refactoring C++ code is typically far too difficult. It may merely be the lingering presence of header files, but C++ just lacks crucial malleability. Changing anything at all becomes a major chore.
C++ is the cornerstone of software engineering. Yet, as mentioned before it is a full spectrum language, which can be used either for low level or high level applications.
It is completely natural that other languages have been grown and evolved towards specific software types. And they probably do the job easier than C++ (trying to engineer a dynamic website in C++ would be a real fuss now)
Yet, one great thing about C++ is that its blazing FAST! And as it is really difficult to use and code with ,it may not be used for enterpise related applications- as they don't have really great speed requirements (most of the time at least). But is used very much , and probably will keep up like this, in the research and academic facilities where speed does matter. I can't imagine programming a simulation enviroment in java, as a run circle would take up as much as 20 times more than if it was created in C++.
As for the "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." I certainly disagree. C++ is an Object Oriented Language . Object Oriented Programing enables the programmers to do really careful code planning, memory management. Whatsmore every component/module can be tested/debugged separately and in a much easier way as OOP provides with the best support for unit testing.
This way totally efficient and fast applications can be programed, in cases where other languages would reach their limits (I cannot imagine how I could code an emulation enviroment which takes up 2GB of dynamic data into the RAM and perform constant and painful processing over them for more than a million emulation queries).
I don't believe that C++ has somewhat lost its value, I just believe that the new wave of software engineers are not up to programing the "hard way". Of course they are not oblidged to and it is best for everyone that they chose the best programing language to them (in means of stability, efficiency and scalability). C++ will definately stay around for 10 to 15 years, but it will not be massively used.
interesting. back in the 80s I used Lotus 1-2-3, starting with 1A. until 2.2(or 3) it was wholly assembler; thence C. I went from 2.01 (the last assembler release) to the C version. I could watch the screen morph, where before it just snapped. the machines were 8088, of course.
the moral of the story: there are 3 or 4 or 5 "levels" of programming, with 1-2-3 being one level up from systems programming. if that's what one means by "application programming", then C/C++/Assem is appropriate. OTOH, if a G/L (yet another) is what one means, then VB/C#/Delphi/etc. is appropriate. if one writes the G/L in C, one ends up writing a DSL, then the G/L. skip wheel inventing, and find a 4GL you like.
in between we find the java/C# world, which I've always thought were a bit schizo: trying to be both application and systems level.
C++ is great for what it's great for, systems programming. What people often fail to realize is that no language is perfect for every task. When productivity, readability, and maintainability are your main concerns you're much better off with Python (had to get a plug in). But you'd never use Python for a device driver, and you shouldn't use C++ for a database program (although it's way better for that than C).
Eli -- Delphi does have a 'form' of garbage collection: when you destroy an object, all objects that have this as their parent are destroyed first. E.g., when you dispose of a TForm object, all buttons, listboxes, etc. on the form are disposed of first.
Manually instantiated objects must be destroyed.
Certain languages/environments are more dangerous than others. Look at all the buffer exploits for C code, or all of the SQL Injection problems with ASP (classic) or PHP. (Or the performance problems with Java strings in early versions of Java.) While C++ is definately safer than C, it's still more dangerous than C#, Java, or Delphi.
C++ certainly has its faults, but if you can stay out of the worse parts of the neighborhood and use decent quality practices, you can write some very good software in it. I've never bought into the "era of abundance" paradigm, since it encourages sloppy practice and general cycle-wasting.
Wasted cycles cost money, in case you'd forgotten that. It's the "I'm going to drive an SUV because it's 'safer'" argument, while blithely ignoring that the 'safety' costs minimally twice as much to maintain as with any other vehicle; a well-built, safety-conscious smaller vehicle would be perfectly viable--just so long as you don't have the larger gas-guzzlers careering all over the interstate.
Languages that get more done in fewer cycles cost less to run at the plug. Arguments over maintainability will seesaw back and forth over the decades, and that's a separate set of costs, anyway. (SUVs cost more to repair, too, if you want the analogy.)
This is not to say that there isn't some other middle ground. C# is very well thought-out, and very easy to learn for a C++ programmer. (Maybe even for Java programmers, but I don't see a lot of them volunteering.) Not sure about the economics of C# yet, but I'm thinking about it.
"But we've long since left that behind; we live in an era of abundance. We have more computer power than we possibly know what to do with on the desktop. "
Ok - that bit *really* worries me! Why not just advocate badly written code, hell the machine can cope!
But this point:
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous."
is one very well made! I am fed up of dealing with "developers" who have learnt a smattering of php/python or heaven forbid Ruby on Rails it is a real big problem these days - too many hobbyists!
I've not used C# so I really cant comment on it. I do use Java quite a lot and find it does the job well enough...but C++ is my langauge of choice. A well-educated C++ programmer has nothing to fear!
I've always sort of considered C++ the library language. The only way to really glue a language to an OS is to use C++ to create the libraries and such. I mean, look at anything ported from Linux to Windows: the only way they work is through DLLs (or using CygWin or a few other ideas that are less easy for the novice), which are in turn coded through C++. The majority of the DLLs are careful ports of C++ files. C++ is such an integral part of the low-language structure of most OSes that you really can't side-step its use. I mean, can you imagine trying to do anything serious on Linux without gcc?
My frustration is that there are still a number of game programming libraries that require C++, because that's one of the places where speed is still VERY much a factor. You just don't have the same superior output from most other languages as you get with C++... and that's just kinda sad.
There will always be projects where you need as much speed as possible, partly because what you undertake gets more ambitious as machines get faster.
Also, you'll often see parallelization cited as the cure for Moore's Law coming to an end, or at least having reached a flat spot. Well, not all algorithms are parallelizable, and when they are, it's frequently hard to do so, and you lose total CPU efficiency, putting pressure back onto optimizing the heck out of everything. So, the need for speed will never go away, and one might even project from this that the use of C++ will grow!
Take the cement/concrete analogy and run with it a bit. As a new building using ready made carbon fiber panels (mentioned above) rests on a foundation of concrete, so too does your Web application written in [insert fashionable language] rest on a foundation of C.
Maybe we don't need more experts to learn to program close to the hardware. We need just enough to get the hard 'dirty' work done so the rest can do their work. There will always be a need for systems-level programming, the question is how much.
I have never had a problem with C++ and found it more elegant compared to C, but I think that once I discovered Ada (and I am talking the first iteration of Ada, not Ada 95) I picked that up and never looked back.
There is a WHOLE LOT of truth in the fact that if you are going to develop with a language as powerful as C, you need to know what you are doing... design design design. Same goes for a language that is C but now with more complicated interfaces that wrap underlying code... C++ becomes more dangerous in that respect.
It's stupid to make pronouncements as if there is one true language for everything. I would never build a web site in C++. I would never build a GUI in PHP. This is a topic as ridiculous as Mac vs. Windows. Use the right tool for the job or go home.
I just want to correct a couple things:
1) Delphi/Object Pascal doesn't have garbage collection, except possibly in the .NET version. When the language itself is compiled to native code, you do manual memory management. It's still far easier than C++, though I sometimes wish for stack-allocated class instances.
2) C++ blows for kernel programming. See http://www.osdever.net/tutorials/pdf/cpp_kernel.pdf and http://www.osdev.org/wiki/C_PlusPlus. Notice the sheer quantity of runtime work you have to do before actually compiling a kernel with full C++ features. I write a kernel in Object Pascal, and I had to do only a small fraction of that to make a working RTL under the Free Pascal Compiler that would run on bare metal.
C++ is really a language for driver programming or low-level applications programming. Don't try to take it lower or higher than those.
Many people seem to think C++'s niche is 'systems programming' and 'Devices drivers'. That may be true for user-mode level programming. However, C++ has some issues with programing anything in kernel mode. Check out this blog by Adi Oltean, and the white paper it references:
• The use of the C++ compiler as a “super-C” is typically expected to work, but such use of the compiler is at the developer’s own risk.
• It is currently impractical to identify problematic C++ constructs mechanically, so developers must carefully analyze the compiler output to ensure that the generated code is suitable for kernel mode.
• Before committing to the use of C++, you should carefully assess whether it will work for you. In particular, you should test C++ constructs early in the development process, to ensure that the constructs do not cause the problems described in this paper or otherwise violate the principles of kernel-mode driver writing.
• Some of the problems discussed in this paper might not become apparent until near the end of development, and that solving them might require code to be completely rewritten.
• Several of the most insidious problems are extremely difficult to reproduce on demand while testing the driver, so a driver with an inherent unreliability might appear to run for extended periods with no problems and fail at random times. This reinforces the need for careful analysis.
The bullet points in my previous post are quoted from the whitepaper. I should have been more careful to make that apparent.
Funny to see people still using VB as a whipping boy when there hasn't been a new release in over 8 years!
C++ is and will continue to be relevant because it has no real competition in its problem space today. That doesn't say anything about its quality one way or another.
Other tools encroach on the fringes a bit, and every day we seem to see new introductions with potential. They just aren't there yet and sometimes that's simply a question of momentum.
I see C++ as an incredibly unproductive language choice, but when the alternative is simple C or even assembly level coding it is just too hard to argue with. For low-level work it continues to hold a significant advantage.
That doesn't mean a contender based on Algol couldn't invade and compete in this space. Delphi has done well in making inroads partly into C++'s domain and FreePascal has had some benefit in tearing down the wall of propriety around Delphi. Other languages descended through Pascal haven't achieved so much, mostly because of excess academic baggage along with relative obscurity and rapid churn and divergence.
Stability is one of the best things C++ has going for it. Change has been evolutionary at a pace the industry has been able to absorb and implementations aren't so divergent as to cause unnecessary headaches.
"That's exactly why I like C# so much. It's just too bad that we are restricted to one single platform by using it :("
My friend, you CAN run C#.NET programs on Linux/Mac/Solaris machines.
http://www.mono-project.com/Main_Page for more information.
Article made the front page on Digg.
"too many software developers are undereducated and undertrained."
What a lame statement. Same could be said for people that like to code in C/C++ instead of ASM. Languages do not evolve to meet the needs of the lesser educated, how can such a smart guy make such dumb statement.
Portuguese translation of this article - summary.
C++ is OO assembly language. 5 years ago for the majority of apps there was no call for an __asm, now the same might be said for __c++ (sic).
Jeff Atwood wrote "... we live in an era of abundance. We have more computer power than we possibly know what to do with on the desktop."
Even if it was true that "We have more computer power ... on the desktop" then we might still have a scarcity of computer power on servers, on mobile phones, on sensors, on autos ...
My company codes in c++, c, php and Eiffel to name a few. I have to say, Eiffel is seriously amazing. Check out the wikipedia link. Eiffel has Garbage collection, pure object orientation, it's elegant and NOT based on C. Oh, and it's open source. Check it out here actually rates just under C++ in speed, http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=selang2=gpp
Stroustrup's books have always been the only ones I could read through and even enjoy. C++ is the only language I ever relished learning and playing around with. A few years programming with PHP, Java, ASP and the like, and I don't even want to be a programmer anymore.
I loved the prevalence of grammatical and spelling errors in a lot of the responses, especially the ones arguing that C++ programmers just need to be better, more educated programmers. To be a good programmer you need to be aware of what you are writing in all languages. If you can't be bothered to take the time and have a good awareness of your grammar in quick responses to articles, how you can expect to have a good awareness of your code?
But does anybody agree with me that these days we have a lot of "programmers" who don't even know what a bit is? I personally know people who, when implementing some simple network protocol, used string and changed separate characters in it just to change packet's options. They didn't know how to do that on integer field! We're getting dumber programmers who don't even know how to read hex! And they call themselves "programmers", ha ha.
There are only two things wrong with C++: The initial concept and the implementation. (Bertrand Meyer)
And I would say every subsequent attempt to "fix" the original in the various "ISO C++" standards. C/C++ have set back software engineering decades IMO.
I am waiting for the language Z#.
I figure by then the computers will be programming us.
"I'm afraid I can't do that Hal."
We're developers, not English Teachers... Wut a dumm risponse.
Sounds like someone who writes only in VB, and not well. You obviously can't write a lick of real code if you spent the time to worry about the grammar.
I think Bjarne makes a strong point about the undereducation of a lot of programmers. If I'm asked to write a web app I'm going to do it in C#, Ruby, or some other such language, no question about it.
However, if I were asked to do it in C++ I wouldn't miss a beat. This is because I understand memory issues, et al. How many of the *younger* web developers running around really understand it beyond the few articles that they've read?
The other point I want to make has to do with what Joel Spolsky calls "Leaky Abstractions". All abstractions leak to some extent. The ones that can truly understand the lower level abstractions can cope with them better than the ones who can't.
C++ may not be the best tool for everything, but knowing it sure as hell doesn't detract from your skills as a Python programmer.
"But when was the last time you used C++ to write a line of business app or website?"
When said app/website needed something computationally intensive done in a short amount of time. There's a reason why all successful languages today provide facilities for calling into C/C++ (this includes Java).
No matter what language you program in, you can learn a lot about programming by learning another language (or culture).
Its difficult to argue for or against any language unless you know the subtleties of the language, cause these distinction to why you would choose one language over the another.
Comparing C# to C++ can be done at visual level by comparing syntax, but the way each handles the code you write is considerably different (compiled vs interpreted on a virtual machine).
Each language can present a solution to a problem. The context of the problem should help you decide what the appropriate language is to use . Most often the language of choice is the one you know as the computing solution to the problem is thought of in the languages that you know.
I don't believe that we have more computing power than we know what to do with on the desktop. In fact, I think this attitude is ruining the desktop experience. I have a brand-new MacBook Pro; pretty fast, right? Wrong. It feels not a bit faster than my 1 GHz Athlon running GNOME -- no slimline itself -- because of the inefficient software. When IRC clients use 200MB of core and keychain daemons use 100, even while very few desktops have more than 1 GB of ram, we need to reconsider this gung-ho disregard for program efficiency. I agree that high-level languages are wonderful and worthwhile, but we still need to pay attention to our programs' resource consumption for a few years yet.
The comment about speed is not surprising, but nonetheless incorrect. First, there are areas where speed is more of a consideration now than it was five or ten years ago. Second, software is becoming bloatware. Take Vista as an example. I would argue that computers are becoming slower for everyday tasks, because apps these days tend to use a LOT of resources. Build more highways, you get more cars. Build faster computers, you get more resource-hungry programs.
It is true that Windows 98 and the apps we were running at that time will run faster on our current hardware. I don't think we'll see most games being written in Python anytime soon.
The first paragraph from the quote is probably the most important:
"However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts."
From first-hand experience, I know that many Computer Science majors that are graduating today have little to no C/C++ experience and have minimal experience with assembly. Most programming is done with interpreted languages (Java, Perl, etc.). While there is nothing wrong with this, I find it disturbing that Master's students have no idea what a 'pointer' is and how to use it.
Now that I've had my rant...
C/C++ is nowhere near 'dead'. C is still the industry standard for embedded devices, probably because it is so close to assembly - if anybody has ever tried to write a networking library in C vs Java, you'll know why software engineers use C... When you're at ANY level other than the application level (aka.. system-level, kernel, firmware, drivers, etc.) you really need access to the resources and control that C and C++ give you (full blown assembly is usually over-the-top, but it happens in many critical sections).
That being said, there are a lot of applications that C++ just plain doesn't make sense for. I know that using Java for a GUI frontend is a fantastic way to do things. Or for a quick app that 'just works'. But for computationally intensive applications, C/C++ is usually the way to go (unless you're working on supercomputers - most research-grade MPI apps are just now making the transition from Fortran... no pointer-chasing!).
(Just a few of my thoughts).
Strangely enough, I've seen several arguments in favor of C++, but not one mentions video games as a major reason for keeping C++ alive. After all, video games _do_ need speed. You're not going to see Doom 4 programmed in Java, that's for sure.
It seems the main problem is that people are confusing C and C++. You can see that by the usage of the "C/C++" expression.
C and C++ are totally different programming languages.
C code is basically the worst thing one can achieve in C++.
Another problem seems to be that people think C++ is for Object-Oriented Programming. That's not the case at all, while it is possible to do so (it is also possible in C, by the way).
Support for OO in C++ is actually rather limited and its usage is discouraged in favor of Object-Based programming and templates, which are not only more efficient but also type-checked and therefore have correctness enforced by the language.
So basically, when you say "C++ is C with OO" you are two times wrong.
The key features of C++ are exceptions, deterministic resource management through RAII, overloading of value semantics, and templates.
Also, C++ is not dangerous at all. While dangerous things are indeed allowed, you have to write specific code to do so that is easily spotted. If you follow normal code guidelines, the typical problems of a C program (memory leaks, heap corruption, memory "stomping", invalid output, "crashes" far removed from the site of the error) can't happen.
C++ is dangerous in the wrong hands, all too often do i see code written to a degree of abstraction that is frightening. I think this comes from a lack of understanding of software structures and fear. This is how it usually happens. One person who seems to really understand what's going on with a project writes the initial code base and creates and interface. That person leaves the project, then others come on to the project. Rather than modifying the previously written code directly, layers of abstraction are added to avoid modfiying code that's not "understood well". This continues through several teams until you have a sort of house of cards implementation which deviates from any standard design concept. I believe alot of people use C++ because it saves time and certainly the STL is something alot of C programmer envy periodically when they really need a hashmap. Honestly though, I do quite well with C, i actually enjoy C quite a bit, I have pointers, i can't imagine needing anything else. If you're looking for an object oriented approach, i recommend you learn Ruby, it's almost purely OO. C++ does a good job implementing OO features in a compiled language but it pales in comparison to the flexibility an interpreted language can provide such as Ruby. In the end I believe it's a matter of "use what is appropriate, and annoys you less", it's somewhat of a personal choice, we should be glad we have so many choices, and that includes C++.
The fact an IRC client takes 200MB isn't because, as is the point of the argument in this post, the language it is written in doesn't allow the fine enough control to scrape every last bit of memory. You can increase/decrease performance even in higher level languages quite dramatically. Of course we shouldn't have a blatant disregard for the fact we might be playing with other apps, but neither should we be as concerned about every last byte and we can, at times, allow things like garbage collection to takes the reigns for a bit. That's the point he's making. The trouble is that many people merge the two and think they don't have to have any thoughts about performance, which is fine when they're developing it. But when users then combine this with dozens of other like-minded apps things start to get a little sluggish.
You give people an inch and they take a mile, but tbh as a developer I'm very mightly greatful for that inch.
C++ is just a mess. It tries to do too much. STL in particular is horrible.
I'm sorry but the comment "It was an appropriate solution for an era of limited computing resources. But we've long since left that behind; we live in an era of abundance." really destroys your entire argument on the subject.
If you want fast, you use C++. By saying that computers are already fast enough, you aren't answering the question but deflecting it.
I've written a ton of apps in C#. I love the ability to write something rapidly. However, I still prefer C++ because it's not so tightly bound to Windows (and don't bring up Mono) and it doesn't hold my hand quite so much. I know what I'm doing and if I don't, I deserve to have my leg blown off.
I think your post you linked to makes the point beautifully (http://www.codinghorror.com/blog/archives/000224.html). This post is not a bash of C++, it's a plea to program at the right level.
Using C++ (or even assembly) to optimize a 3D game algorithm makes sense. Using C++ to write a line of business data driven web application makes less so.
The trend is to optimize developer productivity over code performance (http://haacked.com/archive/2006/09/13/Premature_Optimization_Considered_Healthy.aspx).
Just look at widgets that run on various desktop platforms such as Vista's sidebar. These things can be written in a *shudder* SCRIPTING LANGUAGE. The sky is falling! Amazingly, my desktop and machine performs great!
C and C++ are only needed until there is an optimizing compiler that can take a high level language and make it as fast as a compiled C program. Then, who would ever use C or C++ again?
This discussion really isn't that complicated. You don't drive nails with a sledge hammer. Different applications require different tools. It's not about C++ vs C#.
Bjarne really sums it up with this quote:
"Often, when people have trouble with C++, the real problem is that they don't have appropriate libraries--or that they can't find the libraries that are available"
When people say C# is high level or Java is high level what they really mean is that extensive class libraries are provided by the language vendor (.NET etc).
I'm tired of hearing that C++ is an unproductive language. It depends on the libraries that are available to you. I can be just as productive, and maybe even a little more productive, using c++ with Qt for builing GUI apps than with java. C++ certainly isn't the best tool for every job, but most people who dislike it are a bunch of goddam whinners. If you think C++ will work for you for a specific task, then use it. If not, use something else. And even if you end up using java, c#, perl, etc. 99% of the time, you should learn to write code in a language like c++ or c to enhance your knowlege of how software works. One of these days when I have enough spare time, I'm planning on learning assembly just for the sake of having a better understanding of how software works. I may never use assembly for real world code, but it might help me write better code in other languages. If nothing else, learning a low level language will give you another tool to use in the future in case you do end up having to do some low level stuff.
Several people have mentioned this, but all the software I use on a regular basis is written in C++, and I can't imagine what it would be like if they were written in some .NET language or Java or worse.
Firefox, Thunderbird, all the video games I play, music and video players, word processor, spreadsheet, audio recorder, Visual C++ Express, VS 2003, etc.
I could go on, but most of these applications task my processor, and would not be as snappy or responsive if written in anything other than C++. For awhile I was using Paint.NET, but it's slow, and I get annoyed with that, so I don't use it. Azureus, the Java bittorrent client, can't hold a candle to the C++-based candidates.
I program video games. There's no question about what language I use for that. Most next-gen consoles are faster than desktop computers, and those games will all be written in C++. Microsoft is pushing the XNA/C# thing for the XBOX 360, which is fine for hobbyists, but commercial game programmers know they can't use a runtime that freezes all threads to do extensive garbage collection and memory compacting for longer than 20 milliseconds. It kills the frame rate.
I estimate 98% of the time I am interacting with a computer, the software I am using was written in C++ and this is probably true for most people. So, how is the importance of C++ diminished?
How well does C++ protect me from myself? Well, I don't aim at my feet, so I rarely shoot them. In other words, when I instantiate objects on the heap, I allow smart pointers or STL containers to keep track of them and deal with memory management. I've worked on C# projects that need weird hacks to keep the runtime from freeing memory that is still being used. The .NET runtime with go ahead blow your leg off for you.
C and C++ aren't powerful, they are primitive. Because of this you have to work more, can create dangerous bugs more easily and will need more time to create a working application. Of course you can do everything in those languages - like you can in Assembler. And sometimes they may even be necessary - like Assembler. But that's not a sign of power.
All this "If C/C++ is to hard then you are to weak" gibberish only shows that those people never tried to create real applications in different languages. It's now about being 'hard', it's about getting the job done. People who choose the wrong tools simply aren't professionals.
I'm an old C++ programmer having cut my teeth with Borland's initial incarnations of the language and moving up to MS C++.
C++ is still useful however, in my opinion, there are better solutions for high level apps.
The good thing is that you can write libraries in it for the stuff that has to be fast, efficient or whatever weird thing it has to do and then bind them to your C#, VB, Java or whatever high level language.
I think that's the way the majority of C++ development will go in the future.
He stated that people don't know where to find libraries that exist. So, for student that is currently using C++ where is there a good place to find such libraries. For example if I wanted to create a Btree. Is there a library out there which contains a template for this type of file structure? I guess what I am saying is that the STL for C++ needs to be updated.
My own experience with people having to implement something, let's call them 'developers', is that they are struggling with the concepts, not so much the language. Take the concept of a virtual base class, of an asynchronous event, or a reference-counted pointer. some languages let you side-step these because they have their management built-in (e.g. java for reference counting) but if you need to optimize for memory usage, you need to still understand this concept so that you can (e.g. java) set the object to 'null' so the garbage collector can take it away when come its time. Pointer aliasing exists in Java, Perl as well, it's just less apparent. And these are the things that fresh students have a harder time to wrestle with, and therefore leading to poorly implemented code, whatever the language. I think that is what Bjarne was mentioning, just that he looked at it from the C++ perspective where these fault very quickly end up in segmentation faults and the likes. In Java, this ends-up as the 250MB resident RAM application, in Perl as the garbage sorted hash, and maybe as an exception in Python. It's like explaining a car's manual shift gearbox to somebody having driven an automatic all along. You'll have a hard time explaining the usefulness of the clutch...
"If a language is deemed "easier" it automatically requires less brains to do the job."
A wise programmer will always use an "easier" language when it meets his or her needs. Unless said programmer is an academe or for some other reason the final product and programmer time doesn't matter.
I guess the best way to find libraries for specific tasks is to just google them. Unlike the class library for java and other languages, it is intended that c++'s STL not be bloated with lots of stuff. That helps keep c++ a generic programming language. I think some of the STL containers use btrees internally. Also, keep in mind that you can use any c library with c++. There may be some exceptions to this, but I don't know of any.
"Delphi... has very good garbage collection"
"Delphi remains the best Win32 dev tool in existence, and a decent .NET dev platform. One which even allows Win32 Delphi apps to be recompiled for .NET, preserving the developer's code base. Something MS did not make available for all the VB and C++ apps that needed to be converted to .NET."
True enough. I still hate the language with a passion. I worked with C# for only 3 weeks before falling in love with it and realizing all the drawbacks of pascal.
Free Sign Up Today!
100% Free International dating service
100% Free Find Talk with other members in on-line
100% Free Instant creating Your own personal profile
"I guess what I am saying is that the STL for C++ needs to be updated."
Yes, this is no discovery. The standard library is going to be updated for the next standard with useful things like sockets and threads.
"Here, through HTML and other easy means, a wealth of wonders has been drawn out from the average person because the technology that was for so long only available in the hallowed halls of academia became liberated. In case you couldn't see it from your Ivory Towers, this is a good thing!"
I think no one can argue the fact that an increasing number of professional developers are undereducated in programming. Hey, if you're only a hobbyist programmer that develops unimportant stuff, what do I care if you're an incompetent programmer? Professional programmers are the ones who should be more knowledgeable. That's what we're arguing about. That's what Bjarne was addressing.
"We're developers, not English Teachers... You obviously can't write a lick of real code if you spent the time to worry about the grammar."
Disagree; written English is an analog of code. One who expresses himself well in code should be able to do so in their social language as well. Nitpickiness in grammar and nitpickiness in code go hand in hand.
Bjarne is absolutely spot-on with his analysis. C++ is an incredibly powerful toolkit, but the mistake that many have made in the past (including my own organisation) is to attempt to build business apps directly from the lowest level components provided by the language. This is cumbersome, which is why it has been pushed from this niche by VB6, Java and the .NET languages. The correct way to build systems is by providing the basic abstractions (starting with strings, collections, memory management) and build on top of these in layers of increasing abstraction; Java and like languages provide this basic layer "out of the box", which feature has been instrumental in their success.
The sad irony is that we are only now seeing - too late - these sort of facilities standardising in C++, with the advent of STL and boost. Read comp.lang.c++ and you'll see that a lot of the gurus there never go anywhere near a raw pointer, a delete statement or (god forbid) a C-style array, they have all this stuff wrapped - layers of abstraction again.
The sad thing is that by defecting to Java, C# etc we have also surrendered the wonderful expressive power and flexibility of C++; I certainly miss it.
One last point: C++/CLI would appear to offer the best of both worlds, but I see very little evidence of its use - another case of missing the boat I fear.
Use Qt in conjunction with C++ and you evade it's downsides without losing the benefits of this great language. The resulting code will retain the efficency and performance of c++ but will at the same time be easier to read and comprehend since it is much more 'high-level' due to the elegance of the Qt-Library.
listen here you young wippersnapper noobies!!! I've been a programmer eversince you were in diapers and suckling on your poor mamas nipple.Back in my day we used lotus, pascal and just plain old binary and that's the way it was and we liked it.I got one word for all of u youngsters and that's that "Your all totally wrong!". Learn the basics!! and I don't care if it kills You and by the way, FUCK PRODUCTIVITY!!..We used to walk to the computer lab 5 miles uphill in the snow, barefooted everyday just to write programs that You ingrates dismiss with all of your fancy schmanzy codes and opinions. If I had my way I'd settle this the old fashion way and challenge every one of You to an old fashion code write-off. I've written off the best of em , from jobs to gates...I even took out balmer back in 78 back when he was a zitty faced punk in braces and headgear. if any of You young punks want to try me then..Bring it BIATCHES..
"We're developers, not English Teachers... Wut a dumm risponse."
Oh dear. Yet another young wanker who thinks that proper English doesn't matter. Grow up, sonny boy. You probably don't even know when to use "its" and "it's" correctly, and I bet you spell definitely "definately". And the worst thing is, you think it doesn't matter.
No wonder most software is in such a dire state. If you can't get the details right, what hope is there for the big picture?
Software engineering: a contradiction in terms.
C++ is only difficult to people who don't take the time to grasp age=old computing fundamentals. As such, a lot of modern programmers can't even do binary arithmetic and whether you like it or not computing will alwats be 1's and 0'.
Anyway, the point I try to make is that the beauty of C++ is that you can code _within the user's constraints_. All these fancy new languages (note that I code professionally in C# so I am not stuck in the past) leave the developer making brash assumptions that people are happy to install 20+MB runtimes and other such dependencies just to install their app.
For my own shareware apps, there is no other choice than C++. Of course where necessary I mix it with the native frameworks depending on the platform I target. eg. A windows version of my app uses WTL/C++ yet the Mac port is Cocoa/Obj-C for UI and C++ for the model classes. Works beautifully because I took the time out long ago to work out what I was doing!
C++ is too flexible. Yes, in my opinion it's a disadvantage. The most terrible thing is a possibility to inherit the child class from many parent classes. Sometimes, when the application design has to be changed during the implementation, eg. new facts have been identified or because of the inproper design (and - to be honest - we meet such situations very often, although everyone will agree, it's "not good") or the whole design is more "paper like concept" (looking nice on the papaer but not seriously implementable) than "reality model" the implemented application class model seems to be total mess (and many times far away from design concepts). I mean, you can do too many bad things with C++ as in fact it is not to restrictive language. And then, let think about a guy implementing an application for a couple of years, doing total mess, using all the features of C++ without any concept, just to solve the problem and "progress with the schedule"... The guy thinking - "if it is working, it is ok and we don't have to change anything". Then, imagine the guy will change the job and you will have to take care about all this mess and crap. I thing it's impossible to solve many problems with the inproper design and implementation of C++ applications in a sensible period of time. Sometimes it looks, that the best idea is to design and implement the whole thing again, but of course such move is not possible in reality. I think the programming languages have to be more restrictive than flexible. At the end... it's better to think twice because of some restrictions than avoiding them with the manic-like solutions with the usage of "advanced" features of C++. And - to be more honest - C++ is good, but not for all tasks we can imagine (just because "it's faster than Java" and also multiplatform). We don't need the swiss-army-knifes, like plumbers we have to use the set of tools, like : pillers, hammers, cutters, threaders, welding blowpipes and so on... We need to choice a proper language for specific problem. I think the problem with C++ is that many people consider this language as good for almost everything. There are no flexible tools - you cannot hammer in the nails with the usage of pillers, as you cannot write the web application with the usage of C++ (but you can with ASP.NET, some specific J2EE standards or PHP - depending on the complexity of such web application of course).
That's all from me.
"at a time where the degree of effective formal education of the average software developer has declined"
Yes, I work as a tech lead in a major sw company that uses C++
I have to review a lot of C++ code and interview ppl on their C++ knowledge. bottom line is C++ has gazillion amount of accidental complexity, that distracts from solving the problem.
All teh C++ guru I know, are just that C++ guru, they know nothing else, they're not the guys who can come up with a practical solution fast. They always always always come up with a massively overengineered solution, whose performance sucks and that is totally impossible to maintain.
I've been through so many "refactoring" exercise once the dude who wrote the stuff has left and we find that it is always faster to reimplement than trying to fugure it out.
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."
That is so so so so wrong, C++ makes it much easier to shoot yourself in the foot and when you do, there's nothing left of you, leg body arse... all gone.