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

Comments

Tiobe also explains how it determines it rankings

[Colin Smith]

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

 

Re:What language for business logic?

[0racle]

I believe the answer is C.

The answer is always C.

Re:Tiobe also explains how it determines it rankin

[IamTheRealMike]

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.

Re:Tiobe also explains how it determines it rankin

[chargersfan420]

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

Dinosour language

[Nightlight3]

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.

Re:Dinosour language

[wsgeek]

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.