C/C++ Back On Top of the Programming Heap?

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

Comments

Not a ranking of the best or the most

[Relayman]

From the article: "Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written." [Emphasis added]

It's a survey, no more, no less. Using it to make decisions about your career is foolhardy at best.

Re:Buffer overflow

[Artraze]

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

[Junta]

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.