Slashdot Mirror


Objective-C Enters Top Ten In Language Popularity

bonch writes "Objective-C has entered the top 10 of the Tiobe Programming Community Index. Last year, it was at #39. The huge jump is attributed to its use in iPhone and iPad development. C, of which Objective-C is a strict superset, has reclaimed the #1 spot from Java, which slides to #2. Tiobe also explains how it determines its rankings."

79 of 351 comments (clear)

  1. Tiobe also explains how it determines it rankings by Colin+Smith · · Score: 5, Funny

    Don't they just google it like the rest of us?

     

    --
    Deleted
  2. What language for business logic? by tepples · · Score: 4, Interesting

    There is one popular computing platform that requires all programs to be written in Objective-C. There is another popular computing platform that requires all programs to be written in one of the many languages that compile to verifiably type-safe CLR bytecode, but Objective-C is not one of those languages. So if I want to develop an application for both of these platforms, in what language should I express the business logic of the application so that it can be automatically translated into Objective-C and into a CLR-friendly language?

    1. Re:What language for business logic? by 0racle · · Score: 5, Insightful

      I believe the answer is C.

      The answer is always C.

      --
      "I use a Mac because I'm just better than you are."
    2. Re:What language for business logic? by SanityInAnarchy · · Score: 2, Insightful

      There is one popular computing platform that requires all programs to be written in Objective-C.

      Does it? I thought Apple allowed a few other languages, like plain C/C++...

      So if I want to develop an application for both of these platforms, in what language should I express the business logic of the application so that it can be automatically translated into Objective-C and into a CLR-friendly language?

      Unfortunately, the answer would probably be XML. Lots and lots of XML. Just make sure it's not Turing-complete...

      A saner answer (but one I like less) is to develop something which compiles Objective-C to CLR. Maybe it'd work at a higher level (compile Objective-C to C#), or maybe at a lower level (translate Objective-C bytecode to CLR), but either way, that's your only option, because the iStuff is the only platform which actually bans source language. If they found out you did it the other way around (starting in C# and compiling to Objective-C bytecode), they'd kill your app.

      That or just build a web app.

      --
      Don't thank God, thank a doctor!
    3. Re:What language for business logic? by spazdor · · Score: 2, Funny

      Pseudocode.

      (where "automatically" = "delegated to PFY intern.")

      --
      DRM: Terminator crops for your mind!
    4. Re:What language for business logic? by pauljlucas · · Score: 4, Informative

      I thought Apple allowed a few other languages, like plain C/C++...

      They do, but if you want to use any of the functions for things like, say, UI, you need to use Objective-C at some point because their API is only in Objective-C.

      --
      If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
    5. Re:What language for business logic? by dgatwood · · Score: 4, Insightful

      You will, however, almost certainly not share a single line of UI code between a .Net application and an iPhone application anyway. Even if you could write Objective-C code for .Net, you wouldn't be able to make UIKit calls on the other device, making it a moot point. Likewise, even if you could write code in C# for iPhone, you would not have support for Windows UI calls.

      The way you write code in situations like this is an abstraction layer. You write the core code in C or C++, then write an iPhone UI in Objective-C and a WinMo UI in... whatever, and similarly abstract out file reads/writes, etc. You write custom OS-specific code near the boundaries between the OS and your app, then write the core code in a language that's cross-platform.

      For maximum convenience, you should also consider using Core Foundation where possible. You can build and include CFLite for the other devices, and as long as you restrict yourself to that subset of the API, you'll be fine. And on the iPhone side, you can then take advantage of toll-free bridging to use most of those CF objects as though they were the equivalent NS (Foundation) objects.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    6. Re:What language for business logic? by Moridineas · · Score: 2, Informative

      Not on the iPhone (and I assume neither for any of Apple's current non-laptop devices). But for the laptop, yeah, there are plenty of languages.

      Where are you getting this information? I think you might be confused because OSX is not a "laptop" operating system, it covers Mac mini, laptops, and desktops (Mac Pro, imac, etc).

      The clause, section 3.3.3, now reads:

      "Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

      (http://www.appleinsider.com/articles/10/04/08/apples_iphone_4_sdk_license_bans_flash_java_mono_apps.html)

    7. Re:What language for business logic? by Moridineas · · Score: 4, Informative

      I think you must be confused. That would be pretty hard to do, since Objective C is a superset of C! In any case, you're explicitly wrong:

      The clause, section 3.3.3, now reads:

      "Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

      (http://www.appleinsider.com/articles/10/04/08/apples_iphone_4_sdk_license_bans_flash_java_mono_apps.html)

    8. Re:What language for business logic? by Moridineas · · Score: 4, Insightful

      Somewhat interesting to look at (e.g.) the Wolfenstein 3D iphone code...to see just how little Objective-C there can be!

    9. Re:What language for business logic? by blair1q · · Score: 2, Insightful

      A sign of any real application architecture is that it can't.

      The problem isn't in the abstractions in the middle of the program. Those can generally be translated all over the place.

      The problem is at the edges, where the program has to interface with the system (and via the system with the user and other peripherals).

      Not many languages abstract those things in ways that allow applications to just drop in. Which is why everywhere you go someone has come up with the idea of an abstraction layer, so their goodies aren't strongly coupled to a platform in a way that prevents them from moving to a new platform.

      This isn't limited to porting between languages. Even in one language, porting between systems gives you the idea to put in an abstraction layer, thinking all you'll have to do is reimplement that layer for the next system.

      And the concept of an operating system is a successful example of such a layer, but of course nobody gets that, so they have to abstract a layer between the app and the OS as well.

      I've made a good living working around those mistakes.

    10. Re:What language for business logic? by TheRaven64 · · Score: 4, Interesting

      No you can't. Well, you can (in theory, except that back end is painfully buggy), but you also need to use Clang and LLVM to compile an Objective-C runtime for the CLR. You can't compile the Apple one, because it contains per-platform assembly for the message sending, but you can (in theory) compile the GNU one, which is portable. You then end up running one object model on top of another object model, with two conflicting memory models. If anything nontrivial works, you deserve a prize.

      (I am the maintainer of the GNUstep Objective-C 2 runtime and the author of the GNU runtime support and a few other bits of Objective-C in Clang).

      --
      I am TheRaven on Soylent News
    11. Re:What language for business logic? by Anonymous Coward · · Score: 2, Informative

      Objective C is much closer to Java than to C. They both have dynamic runtimes and the latest Objective C is garbage collected.

      It would be just as stupid to say that C# is a C derivative when it's about as close to a Java clone as you can get.

    12. Re:What language for business logic? by shutdown+-p+now · · Score: 2, Insightful

      There is one popular computing platform that requires all programs to be written in Objective-C. There is another popular computing platform that requires all programs to be written in one of the many languages that compile to verifiably type-safe CLR bytecode, but Objective-C is not one of those languages. So if I want to develop an application for both of these platforms, in what language should I express the business logic of the application so that it can be automatically translated into Objective-C and into a CLR-friendly language?

      Quite obviously, a subset of Objective-C that can be compiled to verifiably type-safe bytecode (actually, the correct requirement is "memory-safe"; IL is not particularly typesafe even when it's verifiable - e.g. it lets you declare a union of overlapping int and float, and that will be verifiable).

      Is such a subset possible? I dare say I am an expert on IL, but definitely not on Obj-C, so I couldn't say for sure; but from what I know about it, it's quite possible. All Obj-C constructs seem to be mappable; the problem is with C stuff such as pointers. So, basically, if you can live with just non-pointer and non-array primitive types (structs & unions are ok) and Cocoa classes, this should be mappable. Actually, even pointers are mappable if they're only used for byref parameter passing, with no pointer arithmetic involved, and no fields of pointer types in structs or classes.

      Ultimately, it all hinges on the question of whether there are any Cocoa APIs which do not fit the restrictions outlined above, and which you can't avoid using while developing an iPhone app. Can anyone knowledgeable clarify that part?

      Come to think of it, even if there are some, they can still be wrapped into higher-level Obj-C code, and then your app coded against that higher-level API.

    13. Re:What language for business logic? by JoeMerchant · · Score: 2, Interesting

      I use Qt, write once (in C++), deploy on Windows, Mac, Linux, Symbian, and any number of embedded systems - with native look and feel, and C++ speed.

      I worked for a "visionary" in 2006 who wanted to start an Objective-C shop, he didn't listen to me when I told him that assimilation into Windows was highly probable - it took 6 months before he realized resistance was futile (not to me, but to the industry at large.) Luckily, we stuck with Qt and the port from OS-X to Windows took about one man-week (lots of OpenGL code that wasn't 100% cross-platform).

      Over the last 4 years, Qt has been stable enough that things I wrote to version 4.1 are still compiling (properly) with no modifications in 4.6... that's pretty impressive when compared to other development environments I have worked in.

    14. Re:What language for business logic? by Moridineas · · Score: 2, Insightful

      You're missing the point. The point is not that Objective C is somehow "closer" to Java or not (in reality it's "closer" to Smalltalk), the point is that valid C code is valid Objective C code. That's what "Objective C is a superset of C" means.

    15. Re:What language for business logic? by TheRaven64 · · Score: 2, Interesting

      Or you know, write a run-time that plays the CLR game.

      Yup, that's possible, but you'd have some impedance mismatch and you'd probably not be able to may Objective-C objects to .NET objects, which would rather defeat the point.

      One of the major benefits that clang has over gcc for Objective-C is a clean abstraction layer between the runtime-specific and runtime-independent parts. This means that you can easily add support for a new runtime by adding a new subclass of CGObjCRuntime (getting GNU runtime codegen done before any Apple people started working on it paid off, and they've continued to maintain the abstraction layer). One thing I keep meaning to do is add a runtime that generates calls that can be easily translated into JavaScript by an LLVM back end, with Objective-C objects represented by JavaScript objects.

      BTW, if somebody would properly document the ABI in some place other than source code I would be very happy.

      The GNUstep runtime's ABI is documented in the headers, with comments that autogsdoc can extract into HTML for you. The old GNU ABI is half-heartedly documented (often incorrectly) in the GNU runtime headers. The Apple ABI is not publicly documented, and neither is the hacky set of interfaces between their Objective-C runtime, their blocks runtime, their Foundation framework, and their linker.

      --
      I am TheRaven on Soylent News
    16. Re:What language for business logic? by mdwh2 · · Score: 2, Informative

      Note that Qt is now also the standard SDK for Symbian, so you'll also get 50% of the smartphone market anyway.

    17. Re:What language for business logic? by mdwh2 · · Score: 2, Insightful

      Well Qt won't run on the Amiga either. Clearly, no solution is going to work for 100% of platforms, since there'll always be platforms that don't support it (even for things like Java, that are intended to run on "anything", they aren't supported on everything).

      Covering Windows, Mac, Linux, Symbian is the vast majority of computing platforms out there. True, he won't cover that 5% of the phone market (in fact, a lot more of the phone market, since there's more than just Symbian and IphoneOS). Is there a solution that does better than Qt? (The only one I can think of is Java, in that it'll run on billions of Java phones, perhaps 90+% of the phone market; no, the Apple phones aren't capable of supporting Java either, but there you are.)

    18. Re:What language for business logic? by DragonWriter · · Score: 2, Insightful

      Objective C is much closer to Java than to C.

      All valid C code is valid Objective C code (well, all C code as of the standard at the time Objective-C was created -- I'm not sure to what extent Objective C has tracked evolution of the C standard.)

      Almost no substantial valid Java code is also valid Objective C code.

  3. wha...? by Mark19960 · · Score: 3, Insightful

    They use search engines to determine this?
    Why does this seem odd to me... or even misguided?

  4. Re:Where are the C development jobs? by localman57 · · Score: 4, Insightful

    Embedded Systems. There's lots of work there. And we're getting more valuable all the time, because Universities are increasingly teaching C#, Java, etc. The number of people out there who can program a microprocessor right down to the metal is dropping each year.

  5. Re:Where are the C development jobs? by ClosedSource · · Score: 4, Funny

    Unfortunately the number of projects that require people who can program right down to the metal has also been dropping each year.

  6. Re:Where are the C development jobs? by Panaflex · · Score: 2, Insightful

    They're everywhere! Sure, lots of people say they're writing C++ code (or, C code wrapped in C++), or application development. A lot of C development is OSS too - there's paid work in that area as well. There's TONS of maintenance work, especially in specialized industry controls, monitoring, whatever.

    In other words, it's all around you - just shrouded in mystery. Not many people advertise new C development, but oftentimes it is just a another tool in a developer's arsenal.

    --
    I said no... but I missed and it came out yes.
  7. Re:Tiobe also explains how it determines it rankin by IamTheRealMike · · Score: 5, Insightful
    Indeed they do:

    The ratings are calculated by counting hits of the most popular search engines. The search query that is used is

    +"[language] programming"

    From this I conclude that the results are meaningless. At best it shows that Objective-C programming has resulted in more discussions and questions. Whether it is "popular" or not is a bit more subjective.

  8. Objective-C jumped up on the basis by ClosedSource · · Score: 4, Funny

    of all the posts on Slashdot saying how much it sucks.

  9. Re:Where are the C development jobs? by localman57 · · Score: 4, Informative

    On the higher end platforms, this is true. Projects based on ARM, PowerPC, Infineon Tri-Core, etc projects are definately using a higher level of abstraction, with more developers programming at those levels, and a small number working in device drivers and board-support packages. \ But the flipside is that intellegence is being distributed into lots of devices (automotive being the best example, but also appliances, utility meters, medical devices, etc). Most of these run on small, self-contained micros which cost only a few dollars. C is far and away the language of choice on these platforms. Developers with the knowledge to allow you to get every last drop of performance out of a $2.37 micro, so you don't have to buy the $2.52 one, are in great demand. When you build 100,000 of something, you can afford some up-front development cost to save $.15

  10. Most popular language isn't C by AdmiralXyz · · Score: 4, Funny

    If Tiobe's website is to be believed, the #1 programming language right now is Whitespace.

    --
    Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
    1. Re:Most popular language isn't C by blair1q · · Score: 2, Funny

      And the most popular drink is spit, and the most popular song is "why won't this compiiiii-iiiile?" and the most popular slashdot reply is "Page Down".

  11. Re:Where are the C development jobs? by Chris+Burke · · Score: 4, Funny

    Where are the C development jobs? I have strong C skills, but everything is Java/C++/PHP/Ruby/worse.

    Worse? Fortran? Cobol? Ada?

    Dare I say, Intercal?

    Brainfuck?!

    --

    The enemies of Democracy are
  12. Re:Has been quite a while! by localman57 · · Score: 2, Informative

    Not a blog? Doing a couple of dozen google searches and typing the numbers into Excel doesn't exactly strike me as hard-core Journalism...

  13. Re:Tiobe also explains how it determines it rankin by chargersfan420 · · Score: 5, Funny

    Agreed. My first thought was, "Yay, I'm not the only idiot out there programming with VB!", but after reading that, it's more like, "Yay, I'm not the only idiot out there having problems coding with VB!"

  14. It doesn't exhibit natural popularity. by Anonymous Coward · · Score: 4, Insightful

    All kidding aside, Objective-C isn't the sort of language people use because they want to. Rather, they use it because it's what Apple says they can use.

    Back in the NeXT days, we used it because it was far better than anything else out there. But that was 20 years ago. Times have changed, and we have better programming languages available to us. Even with Objective-C 2.0, it's still somewhat of a relic.

    So it's popularity isn't natural. It's almost fully artificial, based upon the restricted nature of Apple's platforms, especially the mobile platforms where they've literally "outlawed" everything else.

    1. Re:It doesn't exhibit natural popularity. by ceeam · · Score: 3, Insightful

      > Times have changed, and we have better programming languages available to us.

      That's interesting. And if I'd ask you to name another compiled language with dynamic message routing/dispatch it would be what? C libs compatibility is desired.

    2. Re:It doesn't exhibit natural popularity. by DarkDust · · Score: 2, Interesting

      All kidding aside, Objective-C isn't the sort of language people use because they want to. Rather, they use it because it's what Apple says they can use.

      Back in the NeXT days, we used it because it was far better than anything else out there. But that was 20 years ago. Times have changed, and we have better programming languages available to us. Even with Objective-C 2.0, it's still somewhat of a relic.

      Well, over the past 20 years I've played around with a lot of languages and a lot of environments and I do enjoy writing in Objective-C. It makes a few neat things that I like easy, like Duck Typing and delegates. But more than the language I enjoy Apple's APIs. They are very consistent and nicely done. I know it wasn't always like this, and there are still a few dark corners if you really dig into non-common areas, but all in all it really is fun to use. More fun than most C++ APIs, IMHO, and to me also more fun than .NET or Java. I like C# as a language, but I can't stand the .NET API. Likewise, Java as a language is OK (neither great nor bad) but the API is so-so. It's good, but I never really enjoyed using it. But I can say that I do enjoy Cocoa.

      One thing in particular that I like is that due to a few Objective-C language features you can often avoid creating yet another subclass of something, thanks to Duck Typing.

      Now they even added support for C blocks allowing easy anonymous callback functions, which enables a few more neat programming patterns. My favorite scripting language is Ruby and Objective-C is the compiled language that comes closest to it allowing me to make use of design patterns that I learned to love via Ruby.

    3. Re:It doesn't exhibit natural popularity. by TheRaven64 · · Score: 4, Informative

      But more than the language I enjoy Apple's APIs. They are very consistent and nicely done. I know it wasn't always like this

      You might be surprised. Take a look at the OpenStep specification and see how much is familiar. Apple has filed off a few rough edges, but a lot of Cocoa has not changed in almost two decades.

      --
      I am TheRaven on Soylent News
  15. Re:Where are the C development jobs? by Locke2005 · · Score: 4, Funny
    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
  16. Re:Where are the C development jobs? by DrXym · · Score: 4, Insightful
    Go for a C++ job then. Or suck it up and learn a few languages.

    The reason Java and other languages are more prominent these days is because they are more suitable for most business requirements - reliability, scalability, portability etc. Unless an app has to hit the metal, or has hard speed / memory / CPU requirements, chances are C is not the right language to write in any more.

  17. Re:Tiobe also explains how it determines it rankin by Demonantis · · Score: 2, Insightful

    I think popular topic would mean popular language at least to some degree. Or for sure that it is a more used language as search results wouldn't discriminate preferences like actually enjoying the language. Neat to see and know, but wouldn't use it for any significant business related decisions is how I see it.

  18. Re:Tiobe also explains how it determines it rankin by blair1q · · Score: 2, Funny

    But they do count prime-time programming, which is always more popular than the other kinds.

  19. Dinosour language by Nightlight3 · · Score: 5, Informative

    After about two years programming Obj-C/Cocoa for iPhone apps, I can't believe that this ancient experiment in OOP by an amateur compiler writer is still around. Even though it is nominally a compiled language, all the calls to methods as well as accesses to class properties are interpreted -- the name of the method & its args (args have names) is looked up in a hash table by runtime interpreter to find the address, then to push args and call it, every time you invoke it or access a property. The Obj-C creator basically didn't know how to code linker-loader address binding and so he just left that part for the runtime to decode on millions of end users CPUs from there on. He also didn't know about name mangling, and left that part of his job for the future programmers to do manually (method names and args are explicitly named, so you end up with arg named calling methods like [obj method:arg1 count:count]). For adding properties to a class you have enter the same info in triplicate (variable delcaratiom, property declaratiom, getter/setter declaration), so there is lots of cut & paste, doing by hand the job that compiler should have been doing. The syntax is very clunky, inelegant, uneconomical on programmer's time e.g. requiring lot's of jumping back and forth to match/complete nested square brackets, again simplifying compiler writer's job at the expense of busy work for countless programmers from there on.

    In addition to performance & narrow technical issues, the worst fundamental flaw of Obj-C is that the creator didn't understand the value of name space partitioning in OOP (the key tool for building layers of abstraction), so much of that's left largely to programmers, which in Cocoa (API, like win32) resulted in mind-numbing hyper-verbosity, with each class and method names dragging huge repetitive prefixes, with each name spelling out explicitly its whole ancestry back to the stone age. While the Xcode editor is doing heoric efforts in trying to guess what you meant and offer auto-completion of the names as you type, that is the lesser half of the problem (you still end up doing lots of cut & paste of the Cocoa names). The main drawback is when trying to read or modify the code later -- even the simplest algorithm looks complex, any pattern specific to the task at hand is drowned in the mind-numbing sea of repetitive Cocoa verbiage.

    In short, horrible language & API framework. Only someone who grew up with this and never knew anything better could love it. Of course, like everything Apple, buried under the idiotic Coca+Obj-C layer, there are gems of genius, especially the extremely well thought out functionality and high performance graphics & animation engines.

    1. Re:Dinosour language by binary+paladin · · Score: 4, Informative

      I have tried multiple times to get into Objective-C and Cocoa. I just can't do it and Objective-C is why. It's a shitty language with an even shittier syntax.

      You would think Objective-C 2.0 would have made a greater leap in terms of usability (like adding namespaces), but it didn't. We got garbage collection... which isn't even used in iPhone programming!

      As much as I tend to detest Microsoft, I would love to see C#, or a language like it, become more widespread. As far as syntax goes, it's my favorite take on OOP + C.

    2. Re:Dinosour language by mini+me · · Score: 4, Informative

      all the calls to methods as well as accesses to class properties are interpreted

      That is the feature, along with dynamic typing, that makes Objective-C a perfect match for interface programming. Being able to load classes and call methods from string identifiers reduces the amount of code needed considerably when compared to languages that use early binding. Have fun re-implementing something like KVC/KVO in C++.

      Objective-C's problems stem from the fact that it must be able to compile all valid C code. This severely limits the syntax available. Ruby is essentially Objective-C without the C syntax, if you are curious about the difference syntax makes.

    3. Re:Dinosour language by Sycraft-fu · · Score: 4, Insightful

      I've never understood why Apple has such an obsession with Objective C. To me it really does seem like being different for the sake of being different. In the event they really felt like a new language was needed, well, they should have made one (as MS did in the case of C#). Otherwise it makes sense to use C and C++. They produce fast code, they are well supported, lots of programmers know them, etc. To me it seems highly sensible to use C for extremely low level things (like OS kernels), C++ for speed critical/native apps (like much of the rest of an OS) and then a managed language for those things where speed is not important.

    4. Re:Dinosour language by Homburg · · Score: 4, Informative

      Apple did make a new language, intended (thought not actually used) for the Newton. The Dylan language is basically Lisp with a more conventional, Algol-like syntax; it's a pretty gorgeous language, and I wish it had been successful.

    5. Re:Dinosour language by Nightlight3 · · Score: 2, Interesting

      Have fun re-implementing something like KVC/KVO in C++.

      Now that you mention it, KVC/KVO is another one of ridiculous and wasteful (on end user's CPU & programmer's time) "features" of the Cocoa API. Passing simple numeric arguments of time critical functions (such as animation control) as ascii string objects (not just ascii strings, but malloced strings, which need to be parsed & converted into binary integer/float then free-ed) is utter idiocy. If you wish to get file properties, they return you malloced ascii dictionary of ascii name-value pairs, for size, time date,... (all in ascii pairs that need to be parsed back to binary values that your code needs). It's beyond stupid. Similarly, passing 4 byte IP addresses to their CFNetwork APIs (their wrapper around BSD sockets) as malloced objects is just a mind boggling wastefulness. And all that wastefulness on a mobile device, burning away the batteries.

      As with everything Apple, where sparks of genius are smothered by cult-like rigidity and idiocy, they are going to squander again the gigantic edge they had with the iPhone (which is a great device), just as they did it with Apple II after IBM PC took over, then later after pioneering PC GUI with Mac, they lost the market to Windows which was ten years behind, despite the latter being fueled by the famous Microsoft's creativity and excellence. They are now repeating their old pattern with iPhone (and, among others, their religious devotion to the clunky, wasteful Obj-C/Cocoa). In couple years Android and Mobile Windows, or maybe something better, will leave Apple with their usual 5% niche of the market.

    6. Re:Dinosour language by yerM)M · · Score: 3, Interesting

      all the calls to methods as well as accesses to class properties are interpreted

      .

      It's also not quite true. Objective-c message passing is quite fast, only 4x the cost of a virtual table call in C++. If you are really interested in what happens behind the scene, see obj-c fast-path

      Now, namespaces are still a honking good idea.

    7. Re:Dinosour language by Nightlight3 · · Score: 2, Interesting

      There is nothing there that a table of functions pointers along with compiler generated indices for methods/properties, linker/loader address bindings and on rare occasions OS APIs that provide access to these function pointer tables (Windows has such capabilities), cannot accomplish 300-500 times faster (yep, I had single stepped through their method calls & getters/setters, KVO/KVC processing,... and watched tasks that any decent compiler turns into one or two instructions explode into many hundreds of instructions through their runtime interpreter every time you invoke the "feature").

      I have debated Apple guys on SDK forum (until some big guy, evangelist, got annoyed with the heresy and put a stop to the discussion), asking them to show what exactly can't be done hundreds of times faster (with properly integrated compiler/linker/loader) than their runtime hash tables are doing, and I couldn't get one example that could stand after closer analysis of the tasks. Basically, the guy who created Obj-C was toying with OOP concepts (even he doesn't use it any more), he didn't get the key point of OOP (tools for building layers of abstraction, via flexible name spaces and overloading), and somehow he impressed Steve Jobs, who knew even less about compilers and programming, in his Next phase, and everyone is now stuck with half baked language and hyper-verbose wasteful Cocoa, which leave good chunk of the compiler/linker/loader job to the programmers and end users' CPUs.

    8. Re:Dinosour language by wsgeek · · Score: 5, Informative

      I understand why you might think this way, but realize that the language was created by a pretty smart guy -- Dr. Brad Cox -- and he had one main goal in mind: Be a strict superset of C (not even C++ does this: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B#Constructs_valid_in_C_but_not_C.2B.2B)

      He also wanted it to be truly object-oriented and dynamic in every sense. Your comment therefore has some innaccuracies / unfairness to it:
      "The Obj-C creator basically didn't know how to code linker-loader address binding"

      This is by design. It allows dynamic messaging. You can even, for example, send a message to nil and everything is fine.

      "He also didn't know about name mangling"

      Again, only something you need in a statically linked object-inheritance style language like C++.

      "method names and args are explicitly named, so you end up with arg named calling methods like [obj method:arg1 count:count]"

      Again, by design. Named arguments makes Objective-C one of the best languages for code readability. You don't have to wonder what the arguments are!

      "For adding properties to a class you have enter the same info in triplicate"

      Good point -- this is frustrating even in ObjC-2.0. They should get rid of @synthesize and do it automatically.

      "the creator didn't understand the value of name space partitioning in OOP"

      Dr Cox certainly understood. He just wanted to keep things as close to "pure" C as possible, and had a different way of partitioning spaces -- use 2 letter codes. This is primitive but surprisingly effective, and why all Cocoa objects begin with NS. Think of all the typing this saves, and you never have to wonder what namespace context you're in.

      "mind-numbing hyper-verbosity"

      I agree that the Cocoa library objects / methods are verbose, but this is a GOOD thing. Also, other more recent languages do the same with there libraries, for example: http://msdn.microsoft.com/en-us/library/system(v=VS.100).aspx

      "While the Xcode editor is doing heoric efforts in trying to guess what you meant "

      I agree 100% with you -- Code completion in XCode needs to improve

      "you still end up doing lots of cut & paste of the Cocoa names"

      100% agreed -- XCode needs to have something better than their macro insertion stuff to save me a lot of typing.

    9. Re:Dinosour language by DragonWriter · · Score: 4, Informative

      I've never understood why Apple has such an obsession with Objective C. To me it really does seem like being different for the sake of being different. In the event they really felt like a new language was needed, well, they should have made one (as MS did in the case of C#). Otherwise it makes sense to use C and C++.

      Objective-C is a strict superset of C, so anything that can use Ojective-C can use C as well.

      Apple didn't "feel a new language was needed" for Mac OS X and adopt Objective-C; Mac OS X is, in large part, a repackaging of NeXTstep, for which Objective-C was always the primary language. NeXTstep adopted Objective-C (NeXT didn't invent it, though, they licensed the existing language) in 1988 when both it and C++ were young languages, neither one of which had much penetration.

    10. Re:Dinosour language by maccodemonkey · · Score: 3, Informative

      "There is nothing there that a table of functions pointers along with compiler generated indices for methods/properties, linker/loader address bindings and on rare occasions OS APIs that provide access to these function pointer tables (Windows has such capabilities), cannot accomplish 300-500 times faster (yep, I had single stepped through their method calls & getters/setters, KVO/KVC processing,... and watched tasks that any decent compiler turns into one or two instructions explode into many hundreds of instructions through their runtime interpreter every time you invoke the "feature")."

      Again, you're not understanding the language.

      Using things like KVO/Bindings and distributed objects REQUIRES that the functions be addressed by name, not by address.

      Honestly, if you're using Obj-C as a performance language, you're an idiot. Notice how Objective C has no low level primitives? No basic math functions? No OpenGL abstraction? It's mean to be used as a GUI binding language. This is why in Objective C you are supposed to use C code for your logic (or C++ code if you're so inclined) and then Objective C for your GUI. Objective C was in no shape or form designed for low level logic. This is not a deficiency. This is because it makes a damn good language for doing GUIs.

      The reason there is no linking by address is because a GUI needs to dynamically bind against different sections of code by NAME, not by address. In addition, Objective C supports dynamically adding and removing key values at runtime, which again, goes completely against linking by address.

      You clearly don't know what you are talking about, which is probably why you were shut down on the Apple forum. Learn some KVO and bindings on the Mac, understand what Obj-C is for, and then you'll understand why Apple made the design decisions they did.

    11. Re:Dinosour language by maccodemonkey · · Score: 4, Insightful

      iPhone however does have KVO, KVN, and dynamically generated keys (valueForKey, setValueForKey), all of which doesn't work with linking by address.

      You are supposed to write your network code using CFNetwork and BSD sockets. This is as intended. This is also why Cocoa sockets are actually just loosely wrapped CoreFoundation sockets.

      Obj-C is like a screwdriver. You're trying to use a screwdriver like a hammer, and then loudly complaining about it. I'm telling you it's a screwdriver, not a hammer, and that's how it's intended.

      Obj-C is a language for quickly building GUIs. It's not a language for programming the logic. Apple recommends you use C for logic. Apple codes Cocoa itself in C and C++. Obj-C was in no way and shape build for performance situations. That doesn't mean it's a bad language. The things you regard as deficiencies actually make it an extremely strong language for GUI construction. This is also why Apple doesn't try to force you to use ONLY Obj-C.

      Storing objects by name is an EXTREMELY important feature in Obj-C. Yes, it's slow, but as I've said, don't use Obj-C for performance code.

    12. Re:Dinosour language by furball · · Score: 4, Insightful

      I've never understood why Apple has such an obsession with Objective C

      Allow me to explain.

      1. Who owns the language spec? What if there was a modification needed to the language to meet the needs of Apple's hardware that's going to be released to consumers? For example, blocks. How fast could Apple introduce something like that if the language spec was owned by ... for purpose of example, Oracle?

      2. Who owns the runtime? See question 1.

      Objective-C gives Apple the flexibility to make changes as needed to meet their needs without waiting on some standards body or another corporation to get in the way. Apple will not walk away from Objective-C for these reasons.

    13. Re:Dinosour language by shutdown+-p+now · · Score: 2, Informative

      As much as I tend to detest Microsoft, I would love to see C#, or a language like it, become more widespread.

      Have a look at Vala.

    14. Re:Dinosour language by shutdown+-p+now · · Score: 3, Informative

      The Obj-C creator basically didn't know how to code linker-loader address binding and so he just left that part for the runtime to decode on millions of end users CPUs from there on.

      That's by design. It enables dynamic dispatch and delegation.

      (whether that is a good idea or not is another question, but it's intentional, and not because they "didn't know how to do better")

      He also didn't know about name mangling, and left that part of his job for the future programmers to do manually (method names and args are explicitly named, so you end up with arg named calling methods like [obj method:arg1 count:count]).

      Before commenting on programming language design, I would suggest studying the history of said language first. In case of Obj-C, it would be Smalltalk, from which the above syntax of methods names with "args" (they aren't "args", they are just parts of a single method name) comes verbatim.

      And in Smalltalk, it was, quite obviously, not done because the creator "didn't know about name mangling". It was a conscious design choice to improve readability of method calls.

      By the way, if I remember correctly nothing stops you from declaring methods that can be called as e.g. "[foo bar :1 :2 :3]" if you want.

    15. Re:Dinosour language by Nightlight3 · · Score: 2, Interesting

      Dr. Brad Cox -- and he had one main goal in mind: Be a strict superset of C

      That's as worthy a goal as inventing car that is strict superset of the horse carriage or a plane which is strict superset of a hot air baloon. Strict C is not suitable for OOP due to lack of overloading and creation/management of name spaces.

      This is by design. It allows dynamic messaging. You can even, for example, send a message to nil and everything is fine.

      You should't have to execute hundreds of CPU instructions to make a function call that checks for the whether function pointer (or its parent ptr) is null. Three CPU instructions can easily handle it (e.g. OR EAX,EAX; JZ skip; CALL EAX). In fact this dubious "feature" has probably cost me more debugging time than any other "feature" -- an uninitialized/released object quietly returns 0, that breaks something else many steps later, which needs then to be backtracked to the source problem. I would rather the code crashed right there at call, so I can find it on the first crash, rather then reconstructing it from some subtle malfunction much later on.

      Again, only something you need in a statically linked object-inheritance style language like C++.

      There is absolutely no gain (other than saving efforts of the compiler writer at the expense of programmers & end users CPU/battery) in hashing method names and searching them in a hash table for each invocation of class method/property access compared to storing the target function address into an array of pointers (which can be fixed-up/reloacted if needed by loader) and calling them via function pointers retrieved in a single instruction via compiler generated index. The array of pointers, with an extern/export allowing access to it to the app, has full dynamical felxibility equal to anything provided by hashed method names, while using hundreds times fewer runtime CPU instructions (with more complex compiler code instead). Single step once through assembly code of a method call or property access, and recall that all it is doing is one or two instruction worth of actual task.

      Again, by design. Named arguments makes Objective-C one of the best languages for code readability. You don't have to wonder what the arguments are!

      I don't find [obj string:string count:count] any more readable than obj->string(count) or *obj(string,count). It's needless clutter that saved the compiler writer trouble of implementing name mangling & overloading by shoving that part of compiler job to the brains of future programmers. Compiler designer saved himself few weeks at the expense of few hundred million weeks of work for programmers. Great deal.

      I agree that the Cocoa library objects / methods are verbose, but this is a GOOD thing.

      It's a good thing if you are manager who hasn't programmed since college and wish to peek at what some code is doing, without learning the language. Cocoa names are like having manual for the class rewritten over and over in each statement.

      But if you are trying to follow the pattern specific to the task of your code, the vast volume of the Cocoa names smothers it, making even the most trivial algorithm look like rocket science. Dragging with each name its whole ancestry is exactly opposite from the objective of abstraction, which is the key tool in conquering the complexities of programming. All aspects that are not strictly specific to narrow task that some function/method is doing, should be out of sight, just like the one of most valuable abstraction tools in computer languages, functions, hide all the variation of the caller's context and purposes from the implementation of the function. The function knows only the aspect of the world defined by its parameters & return values and need not worry about whether, say rectangle it is operating on is screen rectangle or room floor...

      With its lack of overloading, named args, poor name space partitioning,... the Obj-C is completely contrary to the objectives of abstra

    16. Re:Dinosour language by Graff · · Score: 3, Informative

      For adding properties to a class you have enter the same info in triplicate (variable delcaratiom, property declaratiom, getter/setter declaration), so there is lots of cut & paste, doing by hand the job that compiler should have been doing.

      Looks pretty simple to me:

      @interface Employee : NSObject {
          @private
              int securityLevel;
      }
       
      @property(assign) int securityLevel;
       
      @implementation Employee
      @synthesize securityLevel;
      @end

      Counting just the relevant lines, that takes care of the variable declaration, its properties, and its getter and setter in 3 lines (approximately 82 characters).

      Here's the equivalent in C++:

      class Employee {
          public:
              void setSecurityLevel (int newLevel);
              int getSecurityLevel ();
          private:
              int securityLevel;
      }
       
      void Employee::setSecurityLevel (int newLevel){
              securityLevel = newLevel;
      }
       
      int Employee::getSecurityLevel (){
              return securityLevel;
      }

      That's a grand total of 9 relevant lines (approximately 217 characters).

      Java:

      class Employee{
          private int securityLevel;
       
          public int getSecurityLevel(){
              return securityLevel;
          }
       
          public void setSecurityLevel(int newLevel){
              securityLevel = newLevel;
          }
      }

      7 relevant ines (approximately 153 characters).

      So, in this circumstance Objective-C is about 1/3 of the characters or lines than the equivalent C++ code and about 1/2 of the characters or lines than the equivalent Java code. Objective-C is hardly a complicated or verbose language. I'm sure you could dig around and find languages that could do the equivalent in less code but this is by no means unreasonable.

    17. Re:Dinosour language by Graff · · Score: 2, Interesting

      Thanks for the tips, because win32 APIs feel like a real paradise now.

      Dig into the underlying implementation of a language and it's bound to get a little complicated. Stuff like objc_msgSend is not meant to be used often, it's there to enable you to do odd things that the simple and easy to use APIs don't allow. You use it carefully and build a decent set of methods around that, then use those instead of calling objc_msgSend a ton.

      There's quite a bit of crusty win32 API running around that is way more complex than the internals of Cocoa.

    18. Re:Dinosour language by bar-agent · · Score: 3, Insightful

      Now that you mention it, KVC/KVO is another one of ridiculous and wasteful (on end user's CPU & programmer's time) "features" of the Cocoa API. Passing simple numeric arguments of time critical functions (such as animation control) as ascii string objects (not just ascii strings, but malloced strings, which need to be parsed & converted into binary integer/float then free-ed) is utter idiocy. If you wish to get file properties, they return you malloced ascii dictionary of ascii name-value pairs, for size, time date,... (all in ascii pairs that need to be parsed back to binary values that your code needs). It's beyond stupid.

      What? No. What you describe would indeed be stupid, but that's not what happens.

      All string literals are shared compile-time constants. You can use @"color" in seven different places and they all refer to the exact same address. So you aren't interpreting ASCII strings, but simply doing a pointer comparison. The only time they need to be parsed is when they are part of a key path, like @"moulding.color", and there is a separate function for evaluating key paths so that the common case is easily optimized.

      Furthermore, key values like 13.5 or 2010-May-23 are not stored or passed around in ASCII form, but wrapped in an NSValue object or a subclass, similar to Java's Integer objects.

      --
      i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
  20. As the Fark crowd likes to say by Sycraft-fu · · Score: 3, Insightful

    This.

    Objective-C has a lot of buzz, since Apple has a lot of buzz. That doesn't mean it is getting used in a lot of projects, just that a lot of people are talking about it. Just because there isn't a lot of chatter online about something, doesn't mean it isn't used.

    For example I suspect C++ is actually much higher. Why? Because it is the language of video games by and large. Pretty much any PC and Xbox 360 game are written in C++, usually using Visual Studio. However you don't see a lot of chatter about it online since it is being done professionally and it just kind of an assumed thing in the games industry.

    Well, that makes for a rather large amount of apps out there, even if they don't get talked about all that much.

    Likewise, though I suspect C is high up on the list due to embedded applications, I think that their data on it is flawed. The reason they see so much is likely Linux, which of course uses a lot of C. Fine, but Linux also gets talked about a lot online, since it is open source. So the amount of discussion it generates in relation to code is much higher than a commercial project.

    In general their methods are rather flawed.

    1. Re:As the Fark crowd likes to say by aztracker1 · · Score: 2, Interesting

      I'd say Java and .Net languages (C#, VB) are probably the most popular in terms of use, mainly because they are the most used for internal business development, which is the majority of dev, just fewer users per app. Though if you count web apps and dev, then Javascript is probably #1

      --
      Michael J. Ryan - tracker1.info
    2. Re:As the Fark crowd likes to say by siloko · · Score: 2, Funny

      Javascript is not a language it is a kind of toffee apple . . .

  21. Re:JavaScript by BasilBrush · · Score: 2, Interesting

    People always overestimate the number of other people that are like them in some way. You are interested in Javascript, so you overestimate how many other people it is important for.

    I've programmed for 30 years; a few languages I've used a lot; many languages I've dabbled with. I've never once touched Javascript. I'm likely to underestimate how many people are program in Javascript.

  22. Another sign... by leonbloy · · Score: 2, Interesting

    ... I value most than Tiobe's dummy ranking, is the popularity of tags in Stackoverflow.
    Granted, it correlates more with questions asked by programmers (many of them beginners) than with jobs.

    Anyway, you can see that also there "Objective-C" has a (surprising for me) high position (as well as "iPhone").

  23. Re:Where are the C development jobs? by lgw · · Score: 2, Informative

    Learn Java if you enjoy solving the same business problems over and over again. Kernel programming is still C. Most "C++ jobs" neuter C++ down to the point you're really just using C with classes, easy to pick up if you know C.

    I recently had lunch with a friend of mine who manages Java development. He's switching jobs because the company is switching to $10/hour Java coders, and he wants nothing to do with that. To the current business mindset, if the problem is best solved with Java, it's best solved from another country.

    For some reason this isn't as much of a problem with C# (perhaps because there's so much less open source available in C#), but of course you're competing in a world labor market in any language, it's just a matter of degree.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  24. Re:Strict Superset? by putaro · · Score: 3, Funny

    The whip and high heels.

  25. Re:Strict Superset? by Shimbo · · Score: 2, Informative

    Sorry to troll, but what exactly is a "strict superset"?

    Well, the strict definition is that it's a superset, and it's not an identical set.

    You probably want the non-strict definition which is "we haven't given up on compatibility with C, like the C++ folks did".

  26. Re:Tiobe also explains how it determines it rankin by pizzach · · Score: 3, Funny

    ARGH! Stop artificially inflating VB's results by using VB's name twice in a post!

    --
    Once you start despising the jerks, you become one.
  27. he was emulating SmallTalk dynamic binding by peter303 · · Score: 4, Informative

    Steve Jobs had enticed Xerox Parc people to Apple, then NeXT. So this methodology seemed advanced at the time. Also Objective-C was commercially supported while C++ was still basically an open-source hack in the mid-1980s. I was an independent NextStep developer. It was unclear what would win. But as usual cheap and open beat a language you had to buy.

    When NeXT took over Apple (oops I mean the other way around :-), the new MacOS was NexTStep layered with old Mac APIs.

  28. Re:Strict Superset? by DragonWriter · · Score: 4, Informative

    Sorry to troll, but what exactly is a "strict superset"? A superset is a set that contains another set, in this case Objective-C contains C; all of it. If it didn't contain all of C, then it wouldn't be a superset at all. So what makes a superset strict?

    A simple analogy:

    "Strict superset" is to "superset" as ">" is to ">=".

  29. Re:Tiobe also explains how it determines it rankin by deniable · · Score: 2, Funny

    Hey, there are a lot of people who prefer VB. Matter of fact, I'm not one.

  30. Because it buys you speed in development by SuperKendall · · Score: 3, Interesting

    I've never understood why Apple has such an obsession with Objective C. To me it really does seem like being different for the sake of being different.

    After you use it for a while it grows on you substantially.

    It's simply a different path than other languages have chosen, but it has a lot of power - like KVC observing of property changes on objects, or the way I can use categories to extend libraries I don't have code for.

    And hands down Interface Builder is the most usable GUI development tool I have ever used, which stems directly from how Objective-C interacts with objects. In every other language I ended up abandoning GUI design tools to code UI by hand, but IB is a major partner in every iPhone/Mac UI I write.

    Yes the syntax is verbose but so what? Modern editors (like XCode) code complete a lot of that typing for you. And in any programming, the actual coding is small compared to thinking about approaches to a problem - so in the end it's not that much different time-wise to actually produce working code.

    On top of that though, I think there's an overall savings in time with really well thought out foundation libraries and language abilities that lead to faster coding over many other languages.

    I've used a number of other languages really heavily, from Java to C++ to Scheme - and I think Objective-C in the end, is a really good language combined with very good tools from Apple.

    I've never really seen the point in pining for other languages that do not philosophically match the platform you are targeting. When I was doing some Windows development I used C++ and the MFC. And though I could use other languages targeting the Mac or iPhone, I never much saw the point in doing so when learning the languages the core foundation libraries were written for gives you an insight into how they are likely built and meant to be used.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  31. Re:As an old C programmer, let me say... by shutdown+-p+now · · Score: 2, Funny

    Surely, as an old C programmer, you rather intended to say:

    main(argc, argv)
      int argc;
      char **argv;
    {
      stroke_beard();
      printf("w00t!\n");
      triple_contracting_rate();
    }

  32. Re:Lines of code by Lars+T. · · Score: 2, Insightful

    I think any useful statistics on a programming language would have to include something on the amount of code written in it and project complexity.

    I have a feeling that the popularity of a programming language is actually inversely proportional to the LOC needed for a given task - unless you get paid for LOC.

    --

    Lars T.

    To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  33. Re:Where are the C development jobs? by JoeMerchant · · Score: 2, Funny

    The chip vendors won't even send out a salesman if your projected volume is only 100k.

    You must be exceptionally rude to them, I can't get them to stay away and our volume is sub-thousand.

  34. Re:Strict Superset? by swillden · · Score: 2, Insightful

    Sorry to troll, but what exactly is a "strict superset"? A superset is a set that contains another set, in this case Objective-C contains C; all of it. If it didn't contain all of C, then it wouldn't be a superset at all. So what makes a superset strict?

    A simple analogy:

    "Strict superset" is to "superset" as ">" is to ">=".

    Technically, yes. That's what it means in a math class or a logic class. But that's not what "strict" means in this context.

    What it means here is that Objective-C is a superset, in the sense that any legal and correct C program is a legal and correct Objective-C program that does the same thing. So the "strict" adjective is technically redundant. The reason it isn't redundant in practice is because other languages (notably C++) are close enough to being supersets of C that they're called supersets of C, even though there are some C programs that are not valid in those languages, or that are valid but work differently.

    So, basically, the situation is that "superset" in this context has been abused a little bit, applied to languages that are almost but not quite supersets. So for Objective-C we say it's a strict superset to mean that it actually is a superset.

    Were the meaning what you suggested, the "strict" adjective would be unnecessary, because the only language that is a superset of C but not a strict superset (I'm using the terms correctly here, not loosely as they have been misapplied to C++, etc.) is C itself.

    Of course, for any of the above to make sense, you also have to specify which version of C you're referring to, and you have to pick one that Objective-C actually is a superset of.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  35. Re:Tiobe also explains how it determines it rankin by pookemon · · Score: 2, Insightful

    yeah - I'm betting that 90% of the Java questions are "Why the f*** is this happening?" and "Are the java team on drugs?" or "I'm using Netbeans for my java development and it just f***ed everything - are the Netbeans developers on the same drugs as the java devs?"

    Hardly a measure of it's popularity.

    --
    dnuof eruc rof aixelsid
  36. Re:Where are the C development jobs? by DrXym · · Score: 2, Interesting
    Learn Java if you enjoy solving the same business problems over and over again. Kernel programming is still C. Most "C++ jobs" neuter C++ down to the point you're really just using C with classes, easy to pick up if you know C.

    Why else would a business be hiring you except to solve their problems? Even kernel programming (the few places that require it) are still to address business problems. You might find yourself writing drivers for example.

    I recently had lunch with a friend of mine who manages Java development. He's switching jobs because the company is switching to $10/hour Java coders, and he wants nothing to do with that. To the current business mindset, if the problem is best solved with Java, it's best solved from another country.

    Someone hiring $10 hour coders will get exactly what they deserve. I used to work for a financial firm that set up a large Indian operation (something like 2000 employees). The theory was US programmers cost the company $300 a day, the Indian ones $90 a day. Of course the quality of code was atrocious, development times were far longer, the business knowledge was non-existent, staff were apathetic and and the turnover / retraining was high. So yeah on paper it looked cheap but they got shit for that. After 2 or 3 years of putting up with substandard quality, they sold their Indian operation but they still outsource stuff to India.

    For some reason this isn't as much of a problem with C# (perhaps because there's so much less open source available in C#), but of course you're competing in a world labor market in any language, it's just a matter of degree.

    C# and Java have their own way things of doing stuff but fundamentally they are interchangeable technologies. I expect the labour market for C# is weaker than Java but at the same time its not a niche language. My own opinion is there are plenty of C# and Java jobs out there and if you are in any way competent and can convey that competence during an interview you should have no problem finding a job.

  37. Re:Tiobe also explains how it determines it rankin by mdwh2 · · Score: 2, Insightful

    I also wonder why the story is all about Objective C (complete with the obligatory Iphone and Ipad Slashvertisement), when obviously there are 9 other languages in the top 10. Do they all get a story too? Seems like Slashdot is becoming more and more like an Apple news site...