Objective-C Overtakes C++, But C Is Number One 594
mikejuk writes "Although the TIOBE Index has its shortcomings, the finding that Objective-C has overtaken C++ is reiterated in the open source Transparent Language Popularity Index. The reason is, of course, that Objective-C is the language you have to use to create iOS applications — and as iPads and iPhones have risen in popularity, so has Objective-C. If you look at the raw charts then you can see that C++ has been in decline since about 2005 and Objective-C has shot up to overtake it with amazing growth. But the two charts are on different scales: if you plot both on the same chart, you can see that rather than rocketing up, Objective-C has just crawled its way past, and it is as much to do with the decline of C++. It simply hasn't reached the popularity of C++ in its heyday before 2005. However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights — Java, C++ and Objective C. Yes C is number one (and a close second in the transparent index)."
Java and C duking it out (Score:5, Interesting)
Java's apparent decline seems to be because of the financial slump. Where the number of new enterprise projects using Java has reduced. Most of this work was deferred and is starting to pick up again (at least as far as I can see). Some of the apparent 'decline' in languages is due to the introduction of new languages. The absolute number of projects using any language may be increasing but with new languages being introduced the proportion for any one language becomes diluted.
That said, C deserves to be right up there because it is still completely relevant as a 'lingua franca' (common language) for talking to hardware or operating systems. It also has the same benefits of Java in that the language is small and the convention is to place complexity in the libraries rather than as arbitrarily added keywords. This is not very exciting for many Slashdotters but for regular joes it allows them to get things done while working on huge, long-term projects (where the set of staff that start the project aren't necessarily those that finish it) where being able to follow other people's code is critical. This doesn't make for good press or excitement in the blogosphere or conference circuit but these two stalwarts pretty much let you solve any problem in any computing environment (portability matters!).
Ever tried looking for jobs using C? (Score:5, Interesting)
I don't get it. If you try searching for jobs programming in C, you'll find that almost everything that matches the search is Objective C, C++, or C# (or, on some poorly run job sites,a C++ or C# job where the punctuation got lost and it's displayed as C). Sometimes a job will say C/C++. C is rare as hen's teeth except for embedded development and there aren't *that* many jobs in embedded development.
I just went to monster.com and searched for C. What I found starting at the top was:
-- C++ job that lost the punctuation
-- Objective-C
-- C# job that lost the punctuation
-- C/C++
-- Objective-C
-- C/C++, C#
-- C/C++
-- Objective-C
etc. The first C job was item 14 (and is embedded). The next C job, ignoring the false hits on such things as A B C, was item 24 (also embedded), and C wasn't the main skill required. So how in the world can C be number one?
Re:C Programming Language (Score:5, Interesting)
You will often see comments to the effect that C is like assembler or that you can do anything in C it just lacks some syntactic sugar. But that is very wrong. Yes, you can to some degree emulate object oriented programming in C. But how would you go about changing your memory allocation (malloc) to use a copying garbage collector? Or do lazy evaluation Haskell style? How do you implement zero-cost exception handling? (longjmp is NOT zero-cost because it requires setjmp).
These concepts are easy for a compiler that compiles directly to assembly language. Often less mature compilers will compile to C as an intermediate language, but in that case the compiler will not be able to generate the most efficient code. For example, a compiler that uses C as intermediate step can implement exceptions using setjmp/longjmp but this adds extra code at every function call. A compiler that goes directly to assembler can implement exception unrolling using static knowledge about the stack instead for a so called zero-cost exception handling solution.
Similarly, a compiler using C as intermediate will be forced to use a conservative garbage collector such as the Boehm GC. Using more efficient solutions such as a copying garbage collector is simply not possible without knowledge of the stack layout.
Re:C Programming Language (Score:4, Interesting)
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)
On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
>
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.
*YOU* are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.
But I'm sure you'd like it more than git.
Linus
- - -
From: Linus Torvalds
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)
On Tue, 20 Jan 2004, Robin Rosenberg wrote:
>
> This is the "We've always used COBOL^H^H^H^H" argument.
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:
- the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
- any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
Feel free to make up (d).
Linus
Re:C Programming Language (Score:5, Interesting)
From: Linus Torvalds Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Newsgroups: gmane.comp.version-control.git Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago) ...
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.
And, for a view somewhat less harsh about C++, but still not a case of "C++ roolz, C droolz!", see The Old Man and the C [opensolaris.org], the abstract of which says
Re:fp (Score:5, Interesting)
I'm guessing this was because the authors were exhibiting uselessly "object-oriented" toy programs to illustrate language features. You'd probably have had a different first impression if you'd started with Cocoa and Objective-C. While it hadn't been updated in years and consequently seems to have disappeared down the memory hole, one of Apple's old Cocoa tutorials was something to the effect of "Build a Text Editor in 15 Minutes", where they showed how you could build a TextEdit-like rich text editor with Cocoa in a couple pages of code.
In fact, it's pretty easy figure out how to do this starting from the Xcode "document-based application" template, as there's not much more to it than replacing the label control in the document window with a Text View and implementing a couple methods in the document class to get and set its contents.
Re:C Programming Language (Score:2, Interesting)
Mod parent up. His just ranting and hasn't addressed any part of the C++ Language.
- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
This is no different than the "infinite amounts of pain" when the C std library or any other c library doesn't work.
- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.
This is no different in C. If you chose a particular method of doing something C and years down the road notice it's not very efficient you still need to rewrite your app to fix it.
Re:C Programming Language (Score:5, Interesting)
For all his brilliance, Linus is stupid about some things. One of them is his near complete lack of understanding of C++. He obviously has zero skill in it, but he has plenty of skill at getting up on his pulpit and flaming people who do.
Re:C Programming Language (Score:4, Interesting)
Creating unusual object structures:
I once played around with a state machine framework that was object oriented c. It had a virtual table at the top of one base class and at the bottom of a different one. Using the same layout in the virtual table allowed multiple inheritance without any special effort and without any wasted space. It's the only object structure I've ever played with that I couldn't implement with C++ classes and inheritance (I guess a *really* good C++ compiler might be able to optimize to that structure)
Virtual Static members and member functions:
There are occasionally times when I need polymorphic behavior, but the behavior itself isn't instance specific. As a contrived example, imagine needing to query an instance of an object for the total number of peer objects that are in existence (I'm probably managing a count during construction/destruction). I need to call some member that is class specific, but that member will only need to use static members to execute. As it is this ends up being declared virtual and the this pointer is (needlessly) passed in.
Those are the only two instances I've run across where I actually wrote code up to the point of noticing that I couldn't do that in C++ (I'm actually still shocked ten years later that there's no such thing as a pure virtual static function).
Re:Ever tried looking for jobs using C? (Score:4, Interesting)
Mod parent up. "The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings." That's rather lame. Exactly how do they search for "C", anyway? Do Sesame Street episodes brought to you by the letter C count?
TIOBE is good for generating bullshit headlines and boastful articles about misleading statistics.
The definition [tiobe.com] is pretty simple. They search for: +"<language> programming", then they try to look for false positives to get a "confidence" factor, and then use that to scale the resulting number of hits. They also include some search term qualifiers for certain languages, but I didn't see any listed for C.
This is really, really poor for a language with many false positives like C, because there are so many false positive results returned, but they are only looking at the first 100 results. The first results will have the fewest number of false positives, while the later results will almost all be false positives. What they are doing is assuming a linear relationship where instead it is most likely an exponential dropoff.
The fact that C is now on top is almost for sure due to the rise of false postives due to Objective-C gaining popularity.