Slashdot Mirror

← Back to Stories (view on slashdot.org)

Objective-C Enters Top Ten In Language Popularity

Posted by timothy on from the narrowly-missed-prom-king dept.

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."

24 of 351 comments (clear)

  1. 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

  2. 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...

  3. 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.
  4. 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)

  5. 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)

  6. Re:What language for business logic? by fusiongyro · · Score: 1, Informative

    If you want to develop a cross-platform app for the iPhone and iPad, you're fucked, so don't bother.

    If you want to develop a cross-platform GUI app for Mac OS X, Linux and Windows, your best bet is probably to use Qt, which means C++.

  7. 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 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.

    4. 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.

    5. 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.

    6. 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.

    7. Re:Dinosour language by Anonymous Coward · · Score: 1, Informative

      Ok, first off it isn't interpreting anything, the code is compiled. If we define anything that has a runtime as interpreted then pretty much all code, including C, is interpreted.

      In reality, Obj-C is dealing with data: the object, the method selector and the arguments. This is how message sending works, and is a key component of what Alan Kay saw as true OOP. How you implement it is up to you but all that matters is that an object may or may not respond to a method at runtime. This means I can load extra code at any point, create new methods at runtime, have methods forwarded to ther objects and even call a method on an object on the other side of the world. It sounds like a lot of your argument is based around either not understanding or not liking message sending.

      The rest of your argument seems to revolve around the syntax. Syntax is entirely subjective and each person has their preferences. Some prefer C#, some prefer lisp, some, like me, prefer Obj-C. I find it's message sending syntax (especially interspersed arguments) to be great for readability and the inherent verbosity is great for creating self documenting code. You may not like it, but that's your opinion which you are entitled to.

      But don't paint it as a dinosaur language when it is from the same time period as C++, gave a lot of inspiration for Java, and has an object model that is nearly identicle to Ruby. Especially when it has stuff that other languages have yet to do well, such as duck typing with optional static typing

    8. 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.

    9. 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.

    10. 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.

      --
      Sapere aude!
  8. 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.
  9. 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".

  10. 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
  11. 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.

  12. 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 ">=".

  13. 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.

  14. 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.