C/C++ Back On Top of the Programming Heap? 611
Drethon writes "On this day in 2008, a submission was posted that C/C++ was losing ground so I decided to check out its current state. It seems that C has returned to the top while Java has dropped by the same amount, VB and PHP have dropped drastically, C++ is holding fast but now in third place and Objective-C and C# have climbed quite a bit. 2008 data thanks to SatanicPuppy: 1. Java (20.5%); 2. C (.14.7%); 3. VB (11.6%); 4. PHP (10.3%); 5. C++ (9.9%); 6. Perl (5.9%); 7. Python (4.5%); 8. C# (.3.8%); 9. Ruby(2.9%); 10. Delphi (2.7%). The other 10 in the top 20 are: JavaScript, D, PL/SQL, SAS, Pascal, Lisp/Scheme, FoxPro/xBase, COBOL, Ada, and ColdFusion."
When will people learn... (Score:4, Insightful)
Popularity Contest (Score:2, Insightful)
The Tiobe index is a popularity contest - a pageant for programming languages - so, you get the trend on what's hot, but that is just part of the IT business.
I challenge you to find 5 banks whose core are not built with Cobol, for example.
My point is that real use != trending languages
Re:Java dropped by the same amount (Score:5, Insightful)
Re:When will people learn... (Score:4, Insightful)
Remember, a good Fortran programmer can write good Fortran code in any language. But that doesn't mean that every language is like Fortran.
Not a ranking of the best or the most (Score:5, Insightful)
It's a survey, no more, no less. Using it to make decisions about your career is foolhardy at best.
Re:Java dropped by the same amount (Score:5, Insightful)
Re:Buffer overflow (Score:5, Insightful)
Re:Buffer overflow (Score:5, Insightful)
Given the prevalence of SQL injection attacks, which could be prevented with a single function call, I have to say that buffer over-(and under-) flows are really a red herring. Unless a language makes it literally impossible to write insecure code, lazy and bad programmers will find a way.
Re:Buffer overflow (Score:5, Insightful)
A pocket knife doesn't implicitly create objects or fail to cleanup if you forget to make your destructor virtual.
C++ has very complex rules that take years to hone and understand correctly, and even then mistakes are easy to make. The proof is that even today when you go to C++ forums people are still asking about obscure language rules while in Java forums the conversation has moved on to issues of design. Nobody needs to discuss the meaning of language constructs in Java because they are obvious.
It isn't however obvious that an error in your cannonical class definition could cause this code to create a memory leak:
a = b;
Clearly proper use of a tool is important. But tools without safety features are more likely to cause accidents.
Re:Windows kernel is C (Score:2, Insightful)
Re:Java dropped by the same amount (Score:5, Insightful)
It isn't just Oracle. IBM is more heavily invested in Java than the owner themselves. Google too. Between those 3, you can't possibly avoid Java or think that it will continue to drop in the Enterprise space. Just not going to happen.
Re:Buffer overflow (Score:5, Insightful)
Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.
Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore. First, compliers represent the result of the best and brightest and trial and error for optimizing code structures into streams of assembly that are frequently counter-intuitively faster than a person is likely to think of on their own. Secondly, prcossor manufacturers tend to get their latest and greatest instruction sets into compilers, and trying to keep up with those dynamics would be implausible for a human writing special purpose code.
So manually writing in assembly is no longer always faster in practice and in fact usually slower. I don't think the same claim can be made of any particular managed language compared to C/C++.
Although I will agree that language choice *usually* matters far less than algorithmic choices and occasionally people jump to a language change in a project to alleviate slowness only to end up not significantly better than they started because of glaring design problems that dwarf the language performance concerns.
Re:Windows kernel is C (Score:3, Insightful)
Except that Boost is an unholy mess designed by students who threw in everything they thought would be cool without a decent overall approach. If it disappeared overnight I wouldn't shed any tears.
Re:Buffer overflow (Score:0, Insightful)
Everyone that isn't me is an idiot and a bad programmer. I know everything. Watch as I beat my chest for 10 lines.
What a bunch of drivel.
Re:Buffer overflow (Score:5, Insightful)
...And as with most language standards standards, that actually means that a developer can safely begin to use the new feature in portable code starting around the year 2025.
Ah, TIOBE again. (Score:4, Insightful)
TIOBE makes for an interesting toy measure. But for truly reliable conclusions, particularly those related to the health of our favorite technologies, we must instead ask: does NetCraft confirm it?
Re:Windows kernel is C (Score:5, Insightful)
Some parts of boost are excellent, some are crap. Your comment reeks of ignorance.
Some excellent libraries are: optional, bind, any, lexical_cast, multi-index container, graph (documentation is awful though), xpressive, shared_ptr, asio.
Re:Buffer overflow (Score:4, Insightful)
Because too many of these programmers don't program anymore. They just tie together modules and libraries with function calls and templates.
The reason C is still big is because there's just so much stuff out that that is not a PC. On a PC you can get away with being unskilled and sloppy, because memory is getting cheaper, CPUs are getting faster, and users are becoming less discerning. Most computers in the world though are not PCs, they're small things hidden inside of devices and they don't run Windows. Some may be slow, some may be fast, but most have resource constraints of some form. Quite a lot of them come with no third party OS or run time library either. And someone has to write all that stuff in something that's reasonably efficient and portable and C and C++ are pretty much the common choices.
Re:Buffer overflow (Score:4, Insightful)
For a lot of functions it is not difficult to write if more efficiently than some good compilers. It's a trick to optimize it the way you need to for certain resource constraints. You wouldn't want to do that for everything, it would take too long. But it's doable for key functions in run time libraries (ie, writing a memcpy that knows how to use your cache instructions).
The "average case" is fine most of the time but quite often there are exceptions. I've seen people who rely on this stuff too much, who argue until they're blue in the face that STL maps are "proven optimal by people smarter than you".