Objective-C Enters Top Ten In Language Popularity 351
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."
What language for business logic? (Score:5, 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?
Re:JavaScript (Score:3, 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.
Re:As the Fark crowd likes to say (Score:3, Interesting)
Another sign... (Score:2, Interesting)
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").
Re:It doesn't exhibit natural popularity. (Score:3, 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.
Re:What language for business logic? (Score:5, 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).
Re:Dinosour language (Score:3, 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.
Re:Dinosour language (Score:4, Interesting)
.
It's also not quite true. Objective-c message passing is quite fast, only 4x the cost of a virtual table call in C++ [mikeash.com]. If you are really interested in what happens behind the scene, see obj-c fast-path [friday.com]
Now, namespaces are still a honking good idea.
Re:Dinosour language (Score:3, 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.
Because it buys you speed in development (Score:4, 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.
Re:Dinosour language (Score:3, 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
Re:What language for business logic? (Score:3, Interesting)
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.
Re:Dinosour language (Score:3, 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.
Re:Where are the C development jobs? (Score:3, Interesting)
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.
Re:What language for business logic? (Score:3, 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.