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."
C and C++ are two separate and very different languages.
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.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
So is Lisp in some sort of state of perpetual undeath then?
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.
Of this list, C#, Ruby, and Python are clearly the best languages as far as I'm concerned.
;)
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?
The Windows OS kernel is mostly in C with some assembly (just like Unix/Linux/BSD/OSX). The Windows GUI is mostly C++ (but so is KDE).
Support Right To Repair Legislation.
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?
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.
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!
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?
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%
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Home Depot has reported that the hammer has moved up 2 places in the rankings overtaking the Phillips head screwdriver and pliers as the most widely used hand tool. Also moving up in the ranks were the flashlight and the crescent wrench, precipitating the further decline of the Allen wrench and the drill bit in the rankings.
Haha, who still uses the Allen wrench? Clearly the Phillips head screwdriver is superior. Newbs.
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.
“Through me you pass into the city of woe:
Through me you pass into eternal pain:
Through me among the people lost for aye.
Justice the founder of my fabric moved:
To rear me was the task of Power divine,
Supremest Wisdom, and primeval Love.
Before me things create were none, save things
Eternal, and eternal I endure.
Abandon all hope, ye who enter here.”
now that C++ will get move semantics
Not will, _has_ move semantics. As of last August.
...since you can get ten times as much done in a single line of perl.
Yes and you will be the only human on earth that knows what it does.
That's called "increasing job security".
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.
...since you can get ten times as much done in a single line of perl.
Yes and you will be the only human on earth that knows what it does.
That's why we call it a "write-only" programming language.
Sheesh, evil *and* a jerk. -- Jade
https://xkcd.com/605/ :)
http://soylentnews.org/~tibman
...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.
For the record, this has been true for a couple of decades. There are only a small number of cases where writing assembly can produce better code, and most of those have to do with application-level semantics that can harness register data to get better results. One example of this is bignum math, where it's frequently useful to sample the carry flag to optimize sequential addition. Even here, however, this effect is usually achieved by compiling the C code to assembly and then hand-optimizing only the smallest portion of the code to use the carry/borrow flag.
It depends what you are doing with it - in the server space, .Net is used all over the place (Dynamics CRM, SharePoint, SQL Server, Exchange - all have a dependency on .Net these days).
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.
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.
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?
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.
Comment removed based on user account deletion
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".