C Beats Java As Number One Language According To TIOBE Index 535
mikejuk writes "Every January it is traditional to compare the state of the languages as indicated by the TIOBE index. So what's up and what's down this year? There have been headlines that C# is the language of the year, but this is based on a new language index. What the TIOBE index shows is that Java is no longer number one as it has been beaten by C — yes C not C++ or even Objective C."
Woohoo (Score:2, Interesting)
Go C!
...Bash? (Score:5, Interesting)
C? (Score:1, Interesting)
That's insane. Exactly what are people writing in C these days???
a bit of latency (Score:5, Interesting)
Java will come back to number 1 in a few years thanks to Android...
Re:C? (Score:5, Interesting)
And why not C++? It has a number of advantages over C...
Re:C? (Score:2, Interesting)
Name three
Re:C? (Score:5, Interesting)
So most of the public will go through their day probably using C or C++ based code 99% of the time and a bit will be say the timesheet software running Java that they access through their C based browser using C based network drivers on viewed through a video card with C based drivers on a C based OS with their packets going through C based routers and switches after using a C based security system to get into the building where they used a C based elevator system to get up to work. Of course many of the above systems use a smattering of other bits such as scripting libraries but those are being run by a C library. The only other language that the average person might encounter would be some Objective-C on their iPhone or some Java on their Android; but again those OS's are basically C.
When they get home and browse the web they then get the full onslaught of servers running a dog's breakfast of PHP, Java, RoR, etc. But those servers are all programmed in.... you guessed it C.
Re:Dying gasps (Score:4, Interesting)
> While I agree that C is a bad language, it has no competition in low-level coding.
Mostly agree. Although I prefer turning all the crap in C++ off to get better compiler support.
> Although C++ could take its role and it even fixes many of its shortcomings (e.g. namespaces)
Uh, you don't remembered "Embedded C++" back in the late 90's early 00's ?
If you think namespaces are part of the problems you really don't understand the complexity of C++ at _run_time_ ...
Namely:
* Exception Handling
* RTTI
* dynamic memory allocation and the crappy way new/delete handle out of memory
* dynamic casts
* no _standard_ way to specify order of global constructors/destructors
Embedded systems NEED to be deterministic, otherwise you are just gambling with a time-bomb.
http://en.wikipedia.org/wiki/Embedded_C%2B%2B [wikipedia.org]
--
There are 2 problems with C++. Its design and implementation.
Re:Woohoo (Score:4, Interesting)
Not going to complain about that.
It's depressing that Objective-C, Ruby and VB.Net have gone up, and see C# go down...
But nice to see C and Bash go up, as well as Java go down. Then again, Java goes down on everything, that's how much it blows. I need a job that doesn't require me to program so much of that. Oh well, occasionally I can get to use C, Bash or Python...
Re:Dying gasps (Score:2, Interesting)
Seconded.
Like Java, C# will be attractive to nubblecake coders due to the ease of use, but I'd have to say, in my experience, the documentation is way better, and, provided you follow what's listed on the Mono project as compatible, you get better cross platform compatibility as well.
Anything can crash with an incompetent coder. If you think C# is bad, imagine what they'd do on a less well documented language like Java, or a much more skill-dependent language like C, C++ or assembler.
Re:Dying gasps (Score:4, Interesting)
After you accept the constraints of an embbebed environment and low level access, C is not a bad language anymore. Any language useable on that kind of environment is at least as bad as C.
Re:Dying gasps (Score:5, Interesting)
I've been using C for so long that I think I've lost objectivity. C is the first language I learned (other than line numbered basic.) In my mind, C is the language all other languages are judged against.
But if there's any truth to this (when did the TIOBE index become the official word?) it makes me wonder if it's not C itself that is making a comeback, but good old fashioned procedural style programming.
All these fancy new languages with their polymorphism, encapsulation, templates and functional features have lost their sparkle. Programmers are rediscovering that there isn't anything you can't do (even runtime polymorphism) with just functions, structs, arrays and pointers. It can be easier to understand, and although it may be more typing, it has the virtue that you know exactly what the compiler is going to do with it.
Re:Dying gasps (Score:4, Interesting)
Oh snap.
See, displying "Yay! it fit in the memory they gave me!" can't be 7 megs.
C was only ever a shorthand for PDP-11 machine language, (back when C was young we'd routinely look at the compiler output. At that point it was passing arguments in registers and Dave Conroy sat in the next cube over working on what has today morphed into* gcc. That's one long lived piece of code.) and in tight spaces and critical loops you want machine language.
Romable node.js would be the only thing I'd consider other the C for embedded code. I don't mind paying that overhead for the inherent asynchronous I/O advantages;, you have to muck around in C a lot to do that so it's worth the trade-off. Anything else just didn't bring enough to the table to warrant the overhead IMO.
Contemporary support for C outside of Bell labs was because of embedded code (a camera gantry project, later, the Halifax postal processing plant) - the RSX11M C compiler written for that became DECUS C which went public and then went everywhere, including replacing the Bell compiler.
* Yeah I know the claim is gcc is a clean rewrite, but logging into toad.com in the early 90s I found DGC commented source in the mix. Jon wasn't aware of it apparently...
Re:Dying gasps (Score:5, Interesting)
Not really. While I agree that C is a bad language, it has no competition in low-level coding.
Oh, there's competion, just not much because it's not wanted or needed. As a hobby I started building an x86 OS from scratch with only a hex editor. From there created an assembler in machine code, then used it to create a small text editor and then assemble a disassembler, then disassembled the assembler (to save me from re-entering ASM), then I began work on creating my own system level language from scratch to build the OS with. The thing is, if you want to make the leanest language just barely above the metal, but still be cross platform, guess what you get? You get C. Seriously.
My syntax was different, but because the op-codes (eg: jmp, the movs and push, pop, call, ret, enter, leave, protected mode & architecture features like the MMU, restricting use of code & stack registers, etc. when you add any features (like functions) you end up creating something almost exactly like C in all but name. The architecture is responsible for C, it's a product of its environment. For instance, I wanted to use multiple stacks: a separate stack for the call stack and another one for parameters / local vars / etc -- In fact I wanted to extend that to support co-routines at the lowest levels possible, all while eliminating stack smashing as a direct exploit vector -- Ah, but because of the way Virtual Memory Addressing works, and because there are dedicated operations for doing single stack per thread function calling, there's a huge performance hit to doing things in other ways down at the low level (I figured out a few tricks, but it's still slower than C functions).
Now, most folks wouldn't tolerate a system level language that was any more inefficient than it had to be, and slightly contrary to the way things want to work at the hardware level just to add features globally that many programs don't need (e.g. namespaces, call-stack security, co-routines, etc), so they'll follow the restrictions of the system and the language produced will come out to be just like C, maybe with slightly different syntax, but all the same idioms. Maybe function calling would be something other than CDECL (instead, for variadics, I pass the number of parameters in a register, and have the callee clean up the stack, reduces code size a bit -- and I have other reasons), but even this is possible to do now in C too at the compiler level. Even when you get to adding OOP to the language, you run into C++ and it's problem with diamond inheritance, and dynamic casting (if you do things the most efficient way possible) -- I allow virtual variables as well as functions to eliminate the diamond inheritance issue with shared bases having variables -- Just make them "virtual", like you would a function, it's slower, another layer of indirection, but if I did it the fast way I'd just be re-implementing C++!
There's a fine line I'm walking, a little too far from the architecture / ASM and my language might as well run via VM, a little less and I might as well just use C/C++. So, the space we have to innovate in to squeeze more worth out of a compilable language isn't really that big. Indeed, when I take a look at GoLang disassembled I see all the same familiar C idioms -- They just give you a nicer API for some things like concurrency, and add a few (inefficient) layers of indirection to do things like duck-typing. Great for application level logic, but I'd still write an OS and its drivers in a C like language instead.
There's a reason why C "has no competition in low-level coding" It's because we don't need a different syntax for low level coding, it's done. As a language designer / implementer when I hear folks say "C is a bad language" I chuckle under my breath and think they might be noobs. Maybe you meant the design by committee approach sucks, but probably not. The features C has it needs to have, the syntax it has, it needs to have, e.g., pointer to a pointer to a