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."
C and C++ are two separate and very different languages.
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
Probably has something to do with it's buzz being 'underground' and its benefits being widely refuted?
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.
If I used a sig over again, would anyone notice?
My impression is that Java will eventually relegated purely to in-house software, for large companies that are heavily invested in Oracle. Most of the goodness of Java comes from the Java API's, and these are on a legal battle. Most OS's are already not including the platform by default. At the end, for independent software companies, and specially for small shops, it feels too risky to invest one's time in learning or keeping up with a language that is controlled by a suing-happy company. As much as I despise Microsoft's ways of polluting languages (remember J++?), I think they are orders of magnitude more trustworthy than Oracle.
Sure. As soon as someone comes up with a language that produces code that runs half way as fast as C on any OS, and that at least pretends to integrate with the rest of the OS. You know, make it nice for everybody else other than developers. Oh, here's a though: how about developers get their heads out of their butts and learn how to be programmers, instead of whining that real languages don't do everything for them?
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.
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.
KDE technically isn't C++. It's written in Qt, which is a set of bastardized extensions to C++ (see meta object compiler) that produce generated C++ code. It's unfortunate that Nokia (who bought Trolltech way back when) invested so much time and effort into something the is effectively obsoleted by Boost.
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
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.
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.
...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.
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?
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.
This sig does not contain any SCO code.
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.
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".