Slashdot Mirror
C Programming Language Back At Number 1
derrida writes "After more than 4 years C is back at position number 1 in the TIOBE index. The scores for C have been pretty constant through the years, varying between the 15% and 20% market share for almost 10 years. So the main reason for C's number 1 position is not C's uprise, but the decline of its competitor Java. Java has a long-term downward trend. It is losing ground to other languages running on the JVM. An example of such a language is JavaFX, which is now approaching the top 20."
but shouldn't it really be at number 0?
Any sufficiently advanced technology is indistinguishable from a rigged demo. -- James Klass
Go ahead, read it for yourself, and tell me how this is supposed to give any meaningful results. They aggregate together things of all kind, to the point where an aggregate doesn't make any sense at all (I mean, hits such as "programming in PHP sucks" or "you must be an idiot to write production code in VB" would count as +1 for PHP and VB, correspondingly!). You can have one language having many job postings, another having many books, and yet another having many basic "how to?" questions and dumbed-down tutorials, and they'd all get the same rating.
In any case, most certainly, at these numbers (Java 18.051%, C 18.058%), speaking of one overtaking another is completely pointless, given the margin of error.
Anyway, if you want to know how popular a particular language/technology is, the simplest - and much more accurate! - way of doing so is to check any popular job search web site. Just keep in mind that preferences vary in different regions, so if you are making career choices, stick to local/national postings, and if you want to see an overall worldwide trend, you have to aggregate data from enough sources.
"Java has a long term downward trend". Wrong. For one, C and Java share the same "downward trend" from 2002 (earliest year on the chart) and 2007. From 2007 to late last year, both C and Java basically stay about the same. Only in the last 6 months or so can you say Java has been doing down and C rising.
In a real emergency, we would have all fled in terror, and you would not have been notified.
There is no way these numbers are anywhere near an approximation of reality.
How many people have real jobs where they get paid to program in Go full-time? Ten guys in the whole world maybe? But it's ranked 15. But when you look at Groovy (the JVM dynamic language) it's ranked at #44, and I personally know at least 20 developers who've used it at a variety of companies (and get paid to do so).
I don't trust these stats at all.
I expect Java to gain ground again as developers create apps for Android phones.
Although the bare-bones Nexus One hasn't sold in huge numbers, HTC have already produced several superb Android-based alternatives, such as the Legend and the Desire. If/when Android becomes the commonplace operating system in the smartphone market, this will lead to a rise in Java development.
In fact, to join in with the recent Apple-bashing (which I whole-heartedly agree with), I'd suggest that mobile app development will move away from the iPhone, in favour of Android phones. When you are investing time and money in app development, there is simply more certainty in developing apps that will live or die on their merits, as opposed to Apple's 'approval' process.
It is now over 2 weeks since Opera Mini was submitted to Apple for approval:
http://my.opera.com/community/countup/
The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, Wikipedia and YouTube are used to calculate the ratings
I feel so much confidence in these numbers.
Seems about as relevant as ranking programming languages to their popularity. Does the fact that C is #1 mean I should start writing my websites with it (I've done it, actually...and it was extremely fast and extremely painful)?
I don't see how this metric has any use at all, especially given their criteria for determining popularity.
C and Java are for different things.
C is a great systems language, it lets you get great performance, interact directly with the hardware and still stay fairly portable. Java is a great applications language, it lets you get work done quickly, runs very fast and is extremely portable and secure (which is getting more important everyday as Microsoft's grip on the desktop industry is on a slow but seriously downward trend).
It makes sense that these two would be at the top, popularity wise.
Mod me down, my New Earth Global Warmingist friends!
FTFA:
Philistines! Heathens! There is nothing more beautiful than a good piece of assembly code.
Haha, you're young (and a douchebag).
Yes, I will take the karma for that.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
And nothing more nightmarish than bad assembly.
Have you seen a thorough Spring implementation?
The cesspool just got a check and balance.
Job listings don't mean very much.
Employees that are very happy with a language, and productive in it, might keep their jobs for years; you may never even know that their companies were using that language. One productive employee might do the job of 10 people in some other language, and maybe that's why they aren't hiring.
Some job postings only made me cringe when I saw them, and many make me think to myself: "all-Microsoft shop, never heard of what X, Y or Z can do". Just because there's a job available, doesn't mean the language is popular; it might even mean the opposite, i.e. all the sane people jumped ship months ago, instead of trying to maintain a steaming pile of code, that a company is now desperately trying to hire people to support.
Don't ever learn one of the stupid programming languages just to get a job. Do something you enjoy...make money without programming if you have to, for awhile, until you find a job that requires languages and platforms that you actually like and can be productive in. Nothing else is worthwhile.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
Java is extremely portable. A Java application can be run anywhere someone wrote a VM for it in C or C++.
The cake is a pie
As a long time C++ programmer who recently went back to C, I can tell you that C feels like a different language if you use it with all the skills you acquired from other languages. As a language C is almost perfect. It's the libraries that makes all the difference.
And nothing more nightmarish than bad assembly.
(I (disagree (there (is (a (missing) (parenthesis (somewhere)) in)) (your Lisp code)))
C has become the English of computer languages. There are so many derivatives - C++, C#, 'Objective-C', Java, and all those other web scripting languages like Actionscript and PHP -- that I can't even keep track of them all. Their syntax are so similar, yet their libraries are from different planets. As for K&R's C, it is probably like the Queen's English - rarely spoken well and often slurred.
Remember when languages really looked different - COBOL, PL/1, Fortran, Lisp? I date myself.
At least it's not Pascal or Fortran.
That was partially my point. Java's security track record for applications is amazing. Look at the current generation game consoles, the only console that has yet to be exploited for piracy in a practical fashion has a Java based security framework.
Java also powers most of the major internet applications available today.
But Java isn't great at everything, C fits in places Java doesn't.
Mod me down, my New Earth Global Warmingist friends!
That'd be the #1 reason on the long list of reasons why Spring sucks. IoC. It's main raison d'être, from the initial release, was to allow the injection of test code, ie, mocks. Why on earth would you ever have "test code" in your production code? Much better to have a test framework instead. Harder to code initially, yes. Less invasively? Immeasurably.
Not only that, it's merely a factory method call that can generally be coded in 4 or 5 lines and be type checked during compilation instead of runtime (a la Spring).
Care to try again and with an actual reason this time?
The cesspool just got a check and balance.
Yep, as I pointed out, it's an application language not a systems language.
reading comprehension++
Mod me down, my New Earth Global Warmingist friends!
Your point is?
What I think you're being snide about (how Java still depends on C) is misguided. That's the point - nobody's saying your system programming languages are dead. At the end of the day, something needs to be a straight sequence of 0s and 1s that the processor can just run, and that's where C dominates. There's a lot of things (like scheduling algorithms) that really can't be written in a higher level language, either.
But at this point, the only reasons you'd need to use C would be for low-level systems programming, as a base for another language (interpreter/JIT VM), or anywhere where you *really* need to manage your own memory or get close-to-assembly performance. (not) Coincidentally, this covers just about everything C is used for nowadays. Many small utilities are now written in Python, particularly small accessory GUI programs on Linux.
Fact is, a higher level language like Java is just faster to program in, and for a basic application it's more than fast enough. But we'll never lose C, at least because all these higher-level fancy applications need to run on something, and nobody wants to write that "something" in straight assembly.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
K&R's book on C is wordy. The true classic is the Revised Report on the Algorithmic Language ALGOL-60. In its original typeset form, it is 19 pages.
Languages which need 1000-page books are badly designed.
Yeah, they do keep saying that. I'm also sure that they can point to dozens of people who stopped iPad development and switched to Android. Somehow, the iPhone and iPad will have to get by with the tens of thousands who remain...
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Test code doesn't end up in production, so I have no idea what you're talking about. Spring is normally used in conjunction with a test framework like JUnit - in fact, Spring contains explicit test harness support (@ExpectedException, JNDI stuff, and so forth).
Spring is good at lots of stuff - annotated transactions, annotated MVC (in Spring 3), etc. etc. IoC is very convenient also, particularly with auto-scanning.
That said, I'm not some huge fan of Java the language. But Java the "ecosystem" (or whatever you want to call it) is pretty amazing.
Spring for Python is interesting too.
Robot programming has become very big lately, and the overwhelming number of microcontrollers out there only use C/C++ (well, and Assembly, but that doesn't count).
Well it could have been worse.
If the only reason you have the IoC code in your code is to facilitate testing, then the IoC code is test code.
MVC (in Spring3)? Really? You mean MVC in Spring 1.x or Spring 2.x sucked? Say it isn't so! So now MVC in Spring 3 is the cat's meow? Excuse me while I take a pass.
Spring's transactions are a massive headache when you need to alter or overload a specific operation. Yeah, it seems "cool" when a simple annotation will give you a "transaction", but later on, when you need to modify one bit of code somewhere in the stream or if you're really daring, have a transaction with rollbacks across multiple operations that weren't envisioned in the original design.... let's just agree to disagree and you can deal with all the crap that Spring heaps on you while you cut and paste code and debug it a week later when individual operations change due to changing requirements and I'll be at the bar sipping something cold and enjoying myself after an hour or two's work.
You didn't even mention Spring Security (ie, Acegi) which was so horribly broken 1.5 years ago that it is completely unusable in anything resembling a commercial application. Why, you ask? (I just know that was on the tip of your tongue) Because Acegi as of the current release at that time uses a token held by a thread, and limited the ability of a token to be held to a single thread. In layman's terms - there's only a single lane on the highway, folks.
I still stand by my statement of years ago: Spring is a solution in search of a problem and is a source of not so subtle bugs which most will only realize once they're in far too deep to easily pull out. It truly deserves a picture next to the kool-aid in the wikipedia story about project killers.
I will agree that JUnit4 is pretty darn decent all by itself. Without Spring.
And just in case you think I haven't worked with it - I've dealt with 4 separate large projects and analyzed the problems in various external codebases in 3 different companies that bought into the Spring kool-aid all the way back to before Spring 1.0. I shamefully admit I was even a proponent in the early days, before I actually used it in a big project. Now Spring has joined Apache Commons in the list of libraries to remove asap.
The cesspool just got a check and balance.
Meh. When I want to show people how bad perl is, I just open up a text editor. Mash my face against the keyboard a couple of times. Then point out that the resulting gibberish is valid perl.
You mean other than assembly?
Yeah, other than assembly is implied ;-)
I do not want to write drivers in asm... ughhh.
Sent from my PDP-11
Well, you're like, entitled to your own opinion, man.
Someone flopped a steamer in the gene pool.
The problem with parentheses grouping/highlighting is that once you're missing a parenthesis, the editor will stop highlighting or worse, highlight the wrong parenthesis.
Lisp'ers just need you to cons() them into a good palette edit. So take 'em out of their nest in your cars() to an indentist, and C to it. Make sure you get parenthetical permission first, though.
I've fallen off your lawn, and I can't get up.
The ultimate imperative language is, of course, Klingon.
(I (disagree ;; <-- Was this it?
;; Auto-indenting editors like Emacs make it easy to catch such mistakes,
;; as does breaking your expressions over multiple lines for readability.
(there (is (a (missing)
(parenthesis (somewhere))
in))
(your Lisp code)))
)
Real programmers use ed(1). Every line counts (or is counted) in ed(1).
"I get the point, but a lot of people get the idea to use Java if you want your apps to run anywhere, which is just idiotic, if you want it run really almost anywhere and are ready to make an extra effort, C is a far better choice than Java."
No, it's really not. Java apps are portable because they're write once, run anywhere there's a JVM. C apps are only portable if you write for every single different platform providing a suitable C compiler exists for each of those platforms.
The issue is that you're confusing a portable application, with an application that can be ported, and having to specifically port for each platform is expensive as it requires much more development time, and it creates more headaches in terms of debugging etc. as you face platform specific issues more often.
The extra effort to go cross platform on C isn't trivial, if you've got to write an IO, networking, graphics, threading abstraction layer and so forth, as well as multiple implementations of for those abstractions layers to get your app to run on multiple platforms then it's likely going to be equivalent to re-writing your entire app a few times over. What's worse is you do not get the inherent security benefits of a language like Java either, meaning the end result is a lot more work, much harder debugging of platform specific issues, much higher chance of security flaws and for what? certainly no worthwhile performance gain.
This is why C is best kept as a systems language- creating things like JVMs, drivers, kernels and so forth it's just fine for. But replacing Java for cross platform application development if Java is an option? that's insane.
Part of being a good developer is using the right tool for the job, anyone recommending C when Java is an option for cross platform development cannot possibly be classed as a good developer, advocating C over Java where Java is an option is simply the sign of a developer who is not capable of picking the right tool for the job.
I'm not even advocating Java as the be all and end all of languages, I don't use it at work, I use C# and .NET because we're a Microsoft based company and C# and .NET simply offer much better development tools, albeit at the expense of portability. It really is about using the right tool for the job to get the best balance of cost, features, and quality possible, and languages like Java have simply matured to offer a far superior solution to many of the more classic languages like C and C++, even if those languages do deserve a special place in our hearts in terms of the behemoths they once were- the languages which you could pretty much just do everything in.
Of course, it's not a new situation either, assembly programmers said about C, what C programmers say about Java. Unfortunately, those who say these are those unable to keep up with the times rather than recognise and sensibly weigh up the benefits and disadvantages of each option.
When Java was two years old, it was utterly unusable and yet overhyped beyond reason, although it brought *nothing new at all*, even inside Sun Microsystems - it was basically a step back from Self-93. (Or rather a whole mile back?) Go actually bears the promise of bringing a "highly concurrent C-level language" into mainstream, at that's something that, unlike Java, makes sense to me. So, OK, it's probably overhyped, but much less than Java was when it was as "old" as Go is today.
Ezekiel 23:20
"anyone recommending C when Java is an option for cross platform development cannot possibly be classed as a good developer,"
Very few systems (especially in house ones) require true cross platform development so that's generally irrelevant anyway.
"advocating C over Java where Java is an option is simply the sign of a developer who is not capable of picking the right tool for the job."
Or maybe its a developer who doesn't have a knee jerk reaction that the tool that leads to the quickest prototype is the best. I've developed back-end trading apps in the past that required the fastest possible throughput of data (we're talking down to milliseconds being shaved off here) to beat the competition and for that Java simply was not an option. We went for a mixture of C and C++ using the standard sockets API and the system was blazingly fast.
Not every "app" is some floppy piece of GUI code that sits there doing bugger all 99% of its life - some apps are back end systems that are maxed out all the working day and for that you can't beat C and C++.
Python has strings. Java has strings. C# has strings.
C has functions that take a pointer and run until they find a \0.
As the CTO of a major global tier one financial services and banking group I manage tons of different software technologies (not to mention the various computing platforms that software has to run on), ranging from Cobol and Java on mainframes to C and TCL on point of sale and EFT terminals through to Java, C# and Visual Basic on servers and ATMs... and of course all the scripting and interpreted languages in between.
I am a dyed in the wool Java person (I personally developed the group's core banking frame work in Java when I still headed up the groups IT architecture division).
I am now a strong advocate for data centre simplification by standardising on .NET for customer facing and branch teller systems (all our teller systems still run on a custom build of OS/2, would you believe)
In my personal capacity (I run a successful independent software development firm as a hobby), I am sold on Embarcadero RAD Studio 2010. To be fair I have been a Delphi fan since version 1 (well since Turbo Pascal 6.0, if you really must know). But switched professionally to Java when JBuilder took off.
Delphi will never enjoy the market position it enjoyed in its heydays... but it remains the staple of the ISV. Lots of software that we use every day is developed using Delphi, ranging from Skype, the Winter Olympics 2010 Rings, Macromedia HomeSite, QuickBooks Point of Sale, Total Commander, Installaware, Yahoo! Go for TV, MySQL Administrator, Dev-C++, TurboCASH , StarUML, SharpE , Cobian Backup, PocoMail, Jabber, XPlite, DynDNS Updater, MultiEdit, SQL Litspeed, CoffeeCup HTML Editor, Windows Shell Extension for M4A music files, PL/SQL Developer and thousands of other software systems that we use every day and take for granted.
So when I started playing with RAD studio 2010, I was impressed at the versatility of the suite. I can do everything from full on .NET (framework 3.5) software development using Microsoft Visual Studio and the Delphi Prism personality to traditional Win32 development. I can even do high performance stuff by taking advantage of the inline assembler and inter-mingling assembly code with my Delphi code. Last night I was impressed that Microsoft tools such as WSDL.exe and XSD.exe were able to generate Delphi code for me to create .NET web services using Delphi directly in Microsoft Visual Studio.
So with Delphi, I have the best of all worlds, and it shouldn't be surprising that as the climate for the independent software developer is getting brighter, we should see a resurgence of those tools that give small development teams platform and technology optionality.
"Very few systems (especially in house ones) require true cross platform development so that's generally irrelevant anyway."
That's too blanket a statement to be valid in the general case, it's certainly true for some companies. As I stated however, our company is Microsoft based, however even here we want to expand some of our apps onto mobile devices and we have a combination of them such that Java is the only real sensible option. Of all the companies I've worked in I've yet to work in one that only ever has a single platform throughout the entire company, they've all had the odd Linux server between their Microsoft servers, a combination of mobile devices and so forth. It's certainly not an uncommon situation to want apps to be portable. There's also the issues of larger companies which have different operating subsidiaries who have to share some apps and data, but who also are given autonomy on IT decisions from subsidiary to subsidiary- Java absolutely excels here, it acts as a common language that just works between subsidiaries pretty much whatever their platform choices.
If you're not developing in house applications and are developing to sell Java makes sense too, because there's no point writing say, a piece of helpdesk software in C# .NET, or C/C++ with multiple binaries to sell when you can just write once with Java and inherently have a product that works across Windows, Linux and Mac OS X greatly expanding your potential clientbase.
"Or maybe its a developer who doesn't have a knee jerk reaction that the tool that leads to the quickest prototype is the best."
Whose talking about prototypes? I'm referring to real working apps.
"I've developed back-end trading apps in the past that required the fastest possible throughput of data (we're talking down to milliseconds being shaved off here) to beat the competition and for that Java simply was not an option."
Really? Apparentlyy the NYSE doesn't agree with you:
http://www.nyse.com/tradingsolutions/transacttools/1204674243385.html
"Not every "app" is some floppy piece of GUI code that sits there doing bugger all 99% of its life - some apps are back end systems that are maxed out all the working day and for that you can't beat C and C++."
Simply put, you're wrong. Java performs just as well as C/C++ in many cases, better in some, slightly worse than others. This is largely because the JIT compiler is better suited to optimising per platform, rather than per architecture like classic compilers. Plenty of case studies here for Java use in HPC for example:
http://www.sun.com/customers/index.xml?soln=31a8487e-0f60-11da-99bc-080020a9ed93&page=1&sort=date&asc=false
The fact that you talk about Java being faster simply for prototyping, the fact you are not aware of the fact that Java performs just as well in many cases as C/C++, and the fact that you do not think Java is used for high load back end processing demonstrates one thing- you do not know enough about Java to be able to correctly evaluate whether it is the right tool for the job or not in the face of C/C++ and are a good example of the type of developer I was referring to as not being a great developer for this reason. It may well be that C/C++ was in fact the right tool for your particular solution after all (i.e. if you had some custom hardware to take advantage of), but as you clearly don't know much about Java, you cannot possibly say for sure whether that was the case or not, despite the fact you are attempting assert otherwise.
The likes of eBay runs on Java and much of Google's back end work is done with Java also. There's a good reason it's the most prominent language in business still today and has been for a while. It's because it does offer advantages, it is versatile, and yes, it ca
If it walks like a duck and it quacks like a duckX_$3[0#GENERAL PROTECTION FAULT
Who ordered that?
C'mon. Be serious.
I do 50% of my coding in C and since the time a hooded man told me "Use the snprintf(), Luke!" I never had a problem :D
All hope abandon ye who enter here.
"Because for every dozen C/C++ applications there are about 1 Java application out there. And since Java runs mostly somewhere in corporate data center, it also has much less exposure to all the security risks."
No, because Java offers inherent protection against buffer overflows, which have been the bane of C/C++ security for, well, forever.
"On the security topic, I have recently seen an example where Java service was easily tricked into dropping whole DB. Java might have removed problems with strings handling, but is still vulnerable to plain logical errors."
Yes, it's called an SQL injection attack. It's a problem that is fairly easy to solve, but most database frameworks don't solve by default. It's not a Java problem though, it's a problem that affects the wider software development industry, I don't think really any major database framework for any platform or any language does a good job of database security right now unfortunately.
"Another good example of "poor" Java security was when folks accidentally managed to "crash" a service: instead of doing anything useful it was in endless loop printing NullPointerException on a console."
That's called having crap developers, it's also a problem that effects any language, and you'd struggle to write a language that can't be broken by people who are incompetent.
"In the end, it all depends on a developer. "Secure" language is a myth. Developers simply do different mistakes in Java."
This is where I disagree, it doesn't all depend on the developer. Java and .NET aren't secure, you're right about that, but they're more secure, and there is less that the developer has to actively do to make sure their applications are secure because again, they don't need to worry about things like buffer overflows. You also have things like assembly security, and so forth too, so that even if an assembly does have a bug in it, the JVM can keep check on what it can actually do if it is compromised. The likes of C/C++ don't have these benefits, you have to manually make sure every single section of code is secure in ways that you simply do not need to in managed languages like Java and C#.
Like you say, that doesn't mean that bad developers can't still write bad software in these languages just as they can in any language, but the fundamental difference is this- in languages like C/C++ it's far too easy for even the most competent developers to miss a security vulnerability, whilst in languages like Java/C++ the window in which developers can accidently create security vulnerabilities is much smaller. So certainly Java and C# apps wont always be absolutely secure, but in general they'll be more secure than C/C++ apps and importantly, they can be developed much more quickly too.
For the web-tier, absolutely nothing beats the Stripes Framework.
No it's not. Companies want desktop-like rich GUI's, and getting web apps to do that and keep them working for browser version N+1 is a pain in the arse. We need some real GUI standards.
Table-ized A.I.
K&R's book on C is wordy. The true classic is the Revised Report on the Algorithmic Language ALGOL-60. In its original typeset form, it is 19 pages.
It's strictly a language spec, though, not a book explaining "why" as well as "what".
By modern standards, it's still somewhat underspecified. Especially in parts such as computed gotos, but there were a few other bits as well - which is why they needed Modified Report on the Algorithmic Language Algol 60, the rationale for which is:
Meanwhile, various defects have been noted in the language definition which have unnecessarily hindered the use of ALGOL. Although the existence of subsets has given some assistance to the compiler-writer and user of the language, numerous problems exist, some of which were noted in the Revised Report.
Hence the need for a detailed commentary and standard interpretation has become apparent. Such a commentary is now available, defining the modifications necessary to produce this Report from the Revised Report.
Finally, it describes a language which didn't have an extensible type system, didn't have pointers, had only 4 basic types (integer, real, Boolean, label) and arrays and procedures thereof, and didn't even have strings as first-class values (yeah, you had "text" type, but you could only produce values of it from string literals and pass it around - no operations on strings at all; you can't even read a string from standard input!).