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."
Java dropped by the same amount (Score:4, Interesting)
Will Java drop even further because of the whole Oracle mess?
I guess I am surprised that Python is ahead of C#, and that Ruby is so low given its underground buzz.
Opinion (Score:4, Interesting)
The C++ longevity is expected. Every engineer worth his weight in salt should be able to write C++ code. (get off my lawn etc.)
I am curious abobut where the C growth is coming from. Embedded stuff? Native libraries for the increasing volume other higher level languages?
Re:Good news! (Score:3, Interesting)
They were never dying. C and C++ underpin all OSes, the Internet, pretty much the multimedia apps you use, the vast majority of games/game engines, etc. and they are the implementation languages of all the 'hip' fad languages.
The TIOBE index is *ABSOLUTELY MEANINGLESS* (Score:5, Interesting)
It's unbelievable that people still pay any attention whatsoever to it. Some company comes up with a ridiculous 'methodology' to gauge the popularity of languages, and people assume that it's actually related in any way to reality.
Further reading:
The best place to start is at TIOBE's own methodology description page: http://bit.ly/h3ftBa
No need to go much beyond that, to figure out that it's a meaningless index. To save you the reading, it more or less boils down to this:
---
The ratings are calculated by counting hits of the most popular search engines. The search query that is used is
+" programming"
---
That's all.
Still need some more convincing:
Why TIOBE isn't all that useful (mild): http://bit.ly/IeG0yA
The TIOBE index is being gamed: http://bit.ly/IeGnt1
It's no short of ridiculous. Time to stop paying attention to it, move along!
On the subject of comparison... (Score:5, Interesting)
You can even click each language and see what comment it is best for. For example, Haskell is top for "This language has a strong static type system" and "When I write code in this language I can be very sure it is correct". Meanwhile, something like PHP is top for "I am sometimes embarrassed to admit to my peers that I know this language" and "This language has many features which feel "tacked on"".
Re:64 bit porting? (Score:4, Interesting)
I would expect that a lot of companies are probably working on importing their legacy systems to work for the new 64 bit systems.
a good amount of legacy systems are written in C, and most of those C written programs are fairly optimized for their platform they were designed to run, and we are starting to switch to 64 bit and multi-core architecture.
You're more or less paraphrasing an email I recall from Linus back in '94 when the 64 bit Digital Alpha port was just beginning. Of course that's 18 years ago not anything new. I think we still have many more years of the "64 bits is new" meme left. With more GOOG effort I could probably find that email. Or it might have been an old Linux Journal article about the alpha port rather than an email. Hmm.
I was pretty late to the conversion to 64 bits compared to most people in the biz. I don't think the debian amd64 port was released until 2007 ish, I think as part of Debian 4.0/etch, although I was using the amd64 port as "testing" (before it became "etch") for at least a year or two earlier.
Some of our amd64 hardware at work is considered legacy now, just because its so old.
I remember in the early years of the 32/64 bit conversion, like half a decade ago, running legacy non-free software like the 32 bit flash player on a 64 bit OS was a pretty interesting problem, but it was all solved a long time ago, so its not interesting anymore. I would imagine someday in the future the windows folks will have similar interesting experiences when they catch up to linux, as they always eventually do.
Re:When will people learn... (Score:5, Interesting)
> except when you write in C++ as though it is C, you get really bad C++
Total nonsense. Almost every game these days is written in C++ and while they all vary in the amount of applied OOP and generic meta programming, the fastest ones use a data driven approach because OOP is SLOW - raw C++ makes dealing with ONE type of object easy, but it doesn't help dealing with performance issues when you have MANY objects. I.e. Template Bloat, lack of virtual dead stripping, and inflated deep hierarchies, to start with.
C is a good language because it forces one to think about runtime performance. When you have some junior coder sticking a virtual function call inside a for loop because he doesn't the three levels of pointers being applied the problem is not the language per say, but programmers who don't understand enough of the hardware to know "There Is No Such Thing As A Free Lunch"
Higher level languages tend to help minimize *developer* time, at the expense of run-time.
Re:When will people learn... (Score:5, Interesting)
Except when you write in C++ as though it is C, you get really bad C++ code.
When you write C++ as though it were C++, you get really bad, terribly inefficient code. If you need to extract maximum performance from your code, a C-with-classes approach to SIMD & multi-core optimisations tends to lead to better results imho. It's very difficult to adhere to what most people refer to 'good C++', because 'good C++' implies nicely encapsulated objects. This doesn't really work so well when you have 256bit wide SIMD registers. Suddenly you find your C++ classes are actually maintaining the state of 8+ objects, and then some of the idioms start unravelling. OOP is currently being stabbed to death by concurrency & parallelism, and there is nothing anyone can do to save it.
Re:Not a ranking of the best or the most (Score:2, Interesting)
Java is poor for memory-intensive codes (Score:5, Interesting)
There is definitely movement away from Java and toward C/C++ for some types of software. Applications bottlenecked by memory performance, like databases and high-performance codes, will often be faster than a language like Java by integer factors. When people assert that Java is about as fast as C/C++ they are talking about code like tight, CPU-bound loops. However, Java is wasteful of memory and CPU cache lines in a way that C/C++ is not under normal circumstances which has a significant adverse impact on the performance of some codes.
On recent processors, memory performance is a bigger bottleneck than CPU performance for performance-sensitive codes. The throughput of CPUs has grown faster than our ability to keep those CPUs fed from memory. In the supercomputing world this started to become evident years ago; memory benchmarks like STREAM became more closely correlated with real-world performance than CPU benchmarks like LINPACK for a great many algorithms. The resurgence of C/C++ is partly driven by this reality since it makes memory optimization relatively straightforward and you can receive large gains relative to Java for modest effort.
A smaller but also important driver away from Java is the GC. The increasing focus on "real-time" and predictable latency for applications like analytics and database engines is complicated when Java's garbage collector is inserted in the middle. This is a chronic point of pain for some applications.
I developed Java for years but my latest project (a real-time analytical database engine) is being written in C++ for the above reasons, among others. Writing high-performance applications of this type is actually pretty painful in Java because you end up doing unnatural things in the language to even approach the efficiency of conventional C++. Anecdotally, many of our C++ developers were doing Java until recently so the statistic does not surprise me.
Re:Buffer overflow (Score:2, Interesting)
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
I am not sure why you do not understand this but....
Idiot programmers are idiots.
We need good programmers. Programming IS complex. It needs to be. There is not a language that is flexible, powerful, fast and will wipe your fucking ass.
Pointing out that your experience in forums is crap.
What you see in C++ forums is what you are looking for. Same with Java.
Java doesn't have obscure commands because it can not do anything obscure.
Just because you are comfortable in Java and are clueless when it comes to C++ says nothing about the languages.
When you start working on some real machines in environments that just get shit done you will see C, C++, Perl, Assembly and shell scripts.
Then you will start looking around and notice PHP shit and Java and bits of shit all over.
In all of that you will see crap coding and good coding. If you can not code well you can go play with with languages that are weak and slow but may allow your shit code to run. But when someone else looks at your code they will still see that it is in fact, Shit.
Re:Eh? (Score:4, Interesting)
https://xkcd.com/605/ [xkcd.com] :)
Re:The TIOBE index is *ABSOLUTELY MEANINGLESS* (Score:2, Interesting)
Agree. A better methodology would be to count references in the top job sites monster, dice, careerbuilder, etc. This will give you the languages that are hot now. You'll see a lot more java than C/C++, for one thing.
Re:Buffer overflow (Score:3, Interesting)
more to 64-bit than that (Score:4, Interesting)
Moving to 64-bit may be a recompile away *for perfectly written code*. In the real world, a lot of 32-bit code assumes you can store pointers in ints, assumes that alignment and packing rules of pointers and ints are the same, prints out pointers using int formatting, uses algorithms that don't scale beyond ~16GB of memory, etc.
Re:Buffer overflow (Score:4, Interesting)
Wow... I haven't touched assembly since about 15 years ago. Trying to program your assembly to outperform a compiler with out-of-order instruction execution on the CPU takes a mad genius. You probably would get about 10x the speed boost by rewriting code to use GP-GPU instead.
In defense of the grandparent, I'm fluent in C++, program it every day, and find it a mindbogglingly complex set of bolted on features that keep expanding and some that overlap each other. From a design perspective, elegant would be the last word I'd use for it, and it really was never a well designed extension on top of C IMO. Objective-C is a MUCH cleaner object extension to C, but it ties you to Apple (yeah, I know about GNUStep, but Apple drives the development of the language). In addition, many C++ features were so poorly implemented that they are rarely used, like try-throw-catch (I have yet to see professional code that uses them - hell, I've seen more code that uses the taboo GOTO for error handling than try-throw-catch). Templates are extremely powerful in C++, but often lead to ugly, obfuscated code. Multiple inheritance has also caused me many headaches compared to interfaces (like Java and Objective-C). C++11 only adds to the feature bloat, but some of the features are more "finally" for me like lambda functions and native multithreading. I've wanted native multithreading since I first started thread programming back in 1991, having to use 4 different thread libraries for 4 platforms (I believe pthreads, Windows threads, MacOS9 threads, and BeOS threads at that time - this was all student programming and I was still learning C++ and very self-motivated). D seems to have cleaned up a lot of the issues I have with C++, but wasn't ready for prime time when I tried it last (several years ago).
I have a love hate relationship with perl, too (another language I use practically every day). It gets the job done, but really, I never needed objects in perl, and haven't used any new features since about perl 3. That said, it is the best cross platform shell language that I've found, and I can write and run quick powerful cross platform scripts.
Re:Opinion (Score:4, Interesting)
Every engineer worth his weight in salt
You're mixing up the phrase "worth its weight in gold" with "worth his salt".
Re:Windows kernel is C (Score:4, Interesting)
I'll give you my opinion as an experienced C++ developer, Boost contributor and C++ standards committee member.
Boost is a set of C++ libraries written by a lot of different people. Some is good, some is bad. Some is old and works with ancient compilers, some is new and requires the latest bleeding edge implementations.The good thing it has about it compared to average code is that it was written by people with a relatively good understanding of the C++ programming language, which is very complex. This typically means that not only it is of better quality than average, but also that it can do more advanced things than what an average developer could think of As such, it is very good for educational purposes, and just reading through the code or the documentation can make people discover very interesting software design. Of course, some libraries have very tedious implementations and are very mature (like PP or MPL), so there is no point in rewriting them yourself: just use them directly.
The fact that it is advanced is however a double-edged sword: to use software in production, you must be able to easily diagnose problems and bugs, even if the code is not yours. Doing that with advanced language constructs can require some non-elementary skills, therefore using those libraries can require a steep learning curve and should thus be seen as an investment.
It's all a matter of studying the library for your needs, evaluating the risks, and making your choice.