Slashdot Mirror
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."
My two favorite languages aren't dying!
Yes, Perl and Ruby combined have twice the share of python. It's really more like 20 times, since you can get ten times as much done in a single line of perl.
Some drink at the fountain of knowledge. Others just gargle.
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?
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!
A shout goes out to this site which actually does a pretty good job of comparing all the languages on 'subjective' attributes such as "I find it easy to write efficient code in this language" (C being top here), or "Code written in this language tends to be verbose" (Cobol and Assembler are worst here, but Java is 3rd place, and that's bad considering it's meant to be a modern higher level language).
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"".
Why OpalCalc is the best Windows calc
The site was loading very slowly so I scraped the 2012 rankings for the curious but impatient:
1 - C - 17.555% .NET - 0.978%
2 - Java - 17.026%
3 - C++ - 8.896%
4 - Objective-C - 8.236%
5 - C# - 7.348%
6 - PHP - 5.288%
7 - (Visual) Basic - 4.962%
8 - Python - 3.665%
9 - JavaScript - 2.879%
10 - Perl - 2.387%
11 - Ruby - 1.510%
12 - PL/SQL - 1.373%
13 - Delphi/Object Pascal - 1.370%
14 - Visual Basic
15 - Lisp - 0.951%
16 - Pascal - 0.812%
17 - Ada - 0.783%
18 - Transact-SQL - 0.760%
19 - Logo - 0.652%
20 - NXT-G - 0.578%
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.
> 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.
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.
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.
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.