Ah, that is a horrible analysis. They are wanting to estimate the number of people with these skills by searching on hashtags, but they search only on the term "objective-c" when what they really should be searching on is Cocoa, iPhone, iPad, iOS and other terms that require one to be working in Objective-C. There's not so much to Objective-C itself that there's a lot of discussion about the language itself compared to what it is used in.
Also, in general I don't buy into these methodologies where someone spends a few hours doing searches on internet boards for certain keywords as a way to estimate the number of people with various skills. It's not been shown to be a valid way of getting accurate data.
Java's Ratio: Slightly less than 2
Obj-C's Ratio: Slightly more than 3
Let's see, I can learn Java and get a job building Android apps or a job building web apps or a job writing mainframe software or writing desktop software or writing server software or building web services or making video games...
...or...
I can learn Objective-C and get a job building iOS apps.
If you need a job and you're deciding between the two, Java should be a no-brainer.
Objective-C is a nice tool to have in your toolbox, but it shouldn't be the one you take out the most.
"I can learn Objective-C and get a job building iOS apps."
...And make $250/hr contract rates. There is ludicrous demand for iOS work. I know several enterprising devs who got into Obj-C over Java purely because the pay is insanely good.
And give me a break. What serious companies are doing web apps or video games in Java in 2012? Sure, Facebook and Twitter are using Java internally, but only for really specific technical challenges forced on to them by scaling. Objective-C is way more fun from a product perspective because you're close to the user. That is desirable for many.
My firm "only" manages to bill at 175/hr on the East Coast (two offices: Boston and NYC) on iOS work, and we've seen a somewhat steady decline in demand. Things might be different in SV. We're pretty content with the amount of work we've already drawn from iOS development, though, so if the cash cow is dead we won't be too upset.
Ouch. As a (Mac) Objective-C programmer for 10 years now, whenever I see stuff like this, it makes me wince that I passed up iPhone development. (I just didn't like how restrictive Apple's rules on the iPhone are.)
> And make $250/hr contract rates. There is ludicrous demand for iOS work.
I don't buy this. Any links?
How many developers can expect such rates in face of more than 250,000 apps in competition? I think only some big publishing houses would pay this big money because in the long run they would get their money back.
Smaller companies would never pay this rate because AFAIK the average income for even very good apps is the range of some thousands or some ten thousand dollars. In case of say 10.000 dollars, all the money would be lost to the developer for just 40 hours of work, that's four days :-)
Ron (of #code2011) did mention something along these lines and I had meant to include it. Thanks for the reminder -- added it into the post with a link to this comment.
Okay, so everyone wants to hire an iPhone developer for whatever awesome app idea they have. Most experienced iPhone developers are already pretty busy.
A further explanation would include the fact that a lot of those people who have a great idea and just need a developer to code it up for them have no idea how the software process works, and the gig will likely involve them stiffing you on the last month's pay and feeling like you ripped them off unless you're pretty experienced at contracting and managing upwards.
The tweets in question were from the #Code2011 hash tag where devs were saying what languages they used in 2011 and from tweets collected by my site http://jobstractor.com which tries to find people hiring devs on Twitter. Hope that sounds a bit more sane :)
I read that. Surveys are fun, but such data shouldn't be taken for measure.
Number of job postings vs average number of offers submitted is one of the first factors that come to mind when seeeking a supply/demand number on the job market, not twitter popularity contests.
The issue with learning objective c is the lack of portability. Yes the language runs on everything via the use of gnustep, but on first appearances its is nextstep ported to modern hardware.
As a disclaimer objective c is my language of choice, my plan this year is to make the code portable.
If you want to make your code portable to Android, consider helping the effort to port Objective-C to it (specifically, enough to get cocos2d running).
Thats insane, why not just port cocos2d itself (I think there might have been an effort before) - after all the original cocos2d was python, so it's been ported across languages before.
It'd be second class in terms of performance. Native code execution speed is one of iOS device's strongest selling points vs. Android, which has a few GC hiccups here and there. Apple is probably more inclined to push the tool that yields the best performance for its users, perhaps even at the expense of developers' productivity.
I think you should look into what MacRuby is. It includes an AOT native code compiler. It's still slower than Objective-C for various reasons — for example, it can't use unboxed primitives and it often needs to do extra work to bridge the gap between Ruby's dynamically typed world and the static C types of framework functions — but it is native code produced by LLVM just like a normal application.
Dude, Laconian - iOS 5 already enables GC (a generational one at that), which already came out for regular Cocoa in in obj-c 2.0
You can bet your socks a lot of devs for typical iOS apps will be using GC.
I dunno what GC algorithm is used for MacRuby, I don't see how the upper limit of performance will be much different since obj-c uses dynamic dispatch the same, and Google/Mozilla is making strides in type inference.
Dyanamically typed languages might be pretty close to static language performance (with properly written code since the JIT is still dumb compared to a human) pretty soon.
What are you talking about? There is no GC in iOS 5. The only GC in the Objective-C world is the one on the Mac and it's pretty much the off the shelf Boehm one.
The only thing iOS has is ARC. This is a compile time reference counting solution. This doesn't work with ruby in it's current form in any way.
| iOS 5 already enables GC (a generational one at that), which already came out for regular Cocoa in in obj-c 2.0
Any links?
Otherwise, I assume you're referring to ARC (Automatic Reference Counting) which is not the same as a Garbage Collector.
In summary, based on code analysis the compiler(I think this works only with the LLVM compiler) inserts code for sending [ release] messages for you.
MacRuby uses the same garbage collector as Objective-C, libauto. Which, incidentally, is not what iOS 5 includes. The "garbage collection" in iOS 5 is Automatic Retain Counting, a compiler feature based on static analysis rather than runtime scanning (it's certainly not generational).
Is MacRuby even a second-class language for developing iOS apps yet? Last I checked they hadn't got anything more than a proof-of-concept going. I thought it was mainly a Mac-focused technology.
No. You can't build iOS apps with it, but you can build OS X apps — even for the App Store.
The main problem in my understanding is the lack of garbage collection on iOS. Someone mentioned that iOS 5 enabled GC, but I think maybe they are referring to ARC (Automatic Reference Counting), which isn't GC even though it solves the same problem.
Yeah, I remember way back when, lrz proposed implementing something very similar to ARC for MacRuby to make it work on the iPhone, and I'm pretty sure somebody actually implemented a proof-of-concept, but I didn't think it went anywhere. I would have been pleased to find out I'd just missed it, though.
I like Ruby. I spend most of my professional day writing Ruby code. I'm definitely not against the idea of adding Ruby as a first class language.
However, Objective-C is similar enough to Ruby that people already well versed in Ruby should have no trouble just using Objective-C. At least for me, when I realized Objective-C was essentially Ruby with C-style syntax, it immediately made sense. I guess YMMV.
The real hard part is learning the beast that is Cocoa/Cocoa Touch. I was able to learn Objective-C in minutes, but learning the frameworks took much longer. You are going to have to do that no matter what language you choose, unfortunately. The APIs have been reasonably consistent across all of the languages they have been implemented on, so I don't think choosing Ruby for your project is really going to speed up the process all that much, if at all.
Objective-C's outlook will be about as strong as the Apple platform will continue to be for better or for worse. Yes, it does exist outside of the Apple ecosystem, but only really in nominal form. What's more, Objective-C work pretty much implies that you'll be doing Apple development...which people may or may not want to get into for hangups. I'm not sure if the app dev craze is a trend that can continue over the long term or not. Should be interesting to see!
Android is full of hello world, copy cap apps, and junk that doesn't get filtered as well as in the Apple app store. So quantity doesn't really amount to much there.
Objective-c is slightly strange compared to other languages but its really just another language anyone can pick up if they put the time and effort into it. Just like you decided to learn clojure or ruby or whatever put some time in, and you can code in any language.
Of all the programming languages I've used (C#, Java, Visual Basic, Python, Javascript, C++, C) is is my favourite.
Not that the other languages are bad but I prefer to write in Objective-C for the frameworks that Apple provides and the syntax (which makes it easy to read IMO). Also the fact that it is a superset of C gives me the ability to get my hands dirty if need be.
It is of course just my opinion. I "do" enterprise Java as my day job. I've programmed in C, C#, VB, Ruby, etc..heck even some assembly language in college and for some reason I find objective-C and the iPhone SDK in general the most painful language/platform I've dealt with in years. I have used Web Objects before (after Java was included) and I wasn't crazy about that either.
I've resorted to using third party engines to do iPhone development. I've settled on CoronaSDK (Lua), but I could easily see using unity3d or some other engine if it fit my needs. I absolutely won't go back to using Objective C. I've come to the conclusion that what language your programming in relates to your quality of life, and after 10 years professionally in Java, I have no desire to learn another platform where it feels like I'm fighting the language/api at every turn. Lua along with the Corona API's feels like fun, and iPhone development is a part time endeavor for me.
1. Verbose, it's very hard keeping ObjC code in 80 columns (if you linebreak too much it's completely unreadable)
2. Lack of generics make the code not feel as safe as the verbose presence of types everywhere would make you think
3. I hear Xcode 4 improved things (and appCode is an actually good IDE), but Xcode 3-generation tooling really is quite terrible, I miss having errors display as I type. Also the autocompletion is garbage, it's barely as good as dynamically typed languages
4. NO NAMESPACES
5. Many solutions feel old/hackish: separate interface/implementation files, macro-looking code (@property/@synthesize never feels right), objective context ("[" and "]", especially as you're repeating them all the bloody time), the severe dichotomy between objects and values or structs requiring things like content wrappings/unwrappings in NSValue (and then there's bloody `id`, which does not look like a pointer but is still an object)
stuff like that. I don't really feel good coding in Obj-C, the frameworks are very complete and often wonderfully thought but I really have a hard time enjoying the language.
1. It's verbose for sure, but why be limited to 80 columns? My screen can show 240 columns, so even showing two files at once, there's 120 columns to play with.
2. Do you actually experience bugs which would be caught by generics? I'd say that most of the time, generics are just a way to add purposeless abstraction without any tangible benefit.
3. Xcode is still terrible, but 4.2 is an improvement over 3.2 at least. Code completion is much better than 3.x.
4. In my eight years of writing ObjC, I have not encountered one single namespace conflict.
5. Agreed, separate interface/implementation files are a historical artefact, and I'd love to see them go. But that's the price of compatibility with C (which is extremely useful).
1. I love that about the language. The 80 character limit has never made sense to me. The resolution of our monitors is so high nowadays that if you've got to a point where linebreaks are making your code unreadable you've got the equivalent of a run-on sentence in English.
2. Totally understand. I've used generics in Java/C# and I've definitely run into instances where I would have loved to have them.
3. Xcode 4 is great for code competition and much better at reporting errors.
4. I haven't worked on massive projects where namespacing could potential be a problem. The 2 character namespace for each class has worked great for me. But again I can totally understand how someone could dislike this.
5. id is amazing. The dynamic nature of Objective-C is the thing I like most about it. Having to wrap ints in NSNumber does get old I admit but id combined with protocols removes so much of the need to cast EVERYTHING in Java/C# before you can perform something on it.
What do you mean by frameworks are incomplete? Third-party frameworks I can understand because there are a lot of novice Objective-C programmers out there making their code available but Apple's frameworks have been near bulletproof for me. Sometimes they are limited (which is Apple's way of forcing you to do things like they do) but in the end if I you need to heavily customize something you can access CoreFoundation and do whatever you need.
I use both Java and Obj-C at work. Objective-c suffers from its C heritage.
1. Pointers (just not useful or needed these days)
2. Memory-management (you don't get ARC unless you're happy to not cater for users using <5.0 (apparently this may not be true. thanks for the comments), and even with ARC you still need to do more than you do in Java)
3. Message-passing (Not bad per se, apart from this: you can send any selector to a nil object, meaning your app will fail silently in many instances. And that is huge.)
4. Header files (the #import is an advantage over usual C, but it's still a pain to remember to import any object before using it)
5. A hodge-podge of syntax: it's smalltalk-inspired syntax, with the more recent dot operator, with the usual C syntax.
6. Painful process of defining/declaring variables. Usual initiallisation, the @property, then @synthesize then initilise it in init: then nil it in viewDidUnload:, then decalloc it in dealloc:.
7. masklinn's point about Namespaces is important, too. Making a library with the standard three letter prefix on every class seems very hackish.
8. masklinn's point about the 'id' variable catch-all also: its very often misused. And your code is full of class checks.
I can live with those things. And that's even if they do make Java look like a nice language. What I really hate is Xcode. (And used to HATE eclipse before encountering Xcode)
1. After you get use to Eclipse's intellisenseque features, using Xcode is like wading through treacle. As one example, initilising a new member field is 1/2 a second job. In Xcode, you have to do what was in the last bullet point. For. Every. Single. Variable.
2. It's debugger/variable inspector, compared to Eclipse, is substandard.
3. Xcode crashes. Often.
4. It just doesn't feel as fast as Eclipse.
5. The debugger can hang on the iPhone a lot, meaning you need to turn it on and off quite often. It's okay in the simulator, I've found.
Regarding ARC: it's handled purely at compile time and works fine with iOS 4 (modulo weak references).
ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.
1. Took a while to get used to but if you don't like pointers then yeah I understand.
2. In iOS (especially before the iPhone 4) memory management is one of the things that allows it to be as smooth as it. Adding GC overhead will eat up precious resources. On desktop this is usually masked by the absurd amounts of RAM most modern machines have.
3. Message-passing is one of the best things about Objective-C. You no longer have to perform null checks because if you structure you code correctly it will continue gracefully. The dynamic nature of Objective-C is what I love most about it.
4. I love the verbose syntax but that is a personal thing I guess. I love structuring my code and selector names so that everything almost reads like a paragraph of text.
I think we have to agree to disagree about Eclipse. I've been using it since University and I much prefer Xcode to Eclipse. To me Eclipse is the slow behemoth eating up my system memory.
I can understand the variable inspector. The GUI in Xcode is throwaway but once I got used to gdb I've grown to like it.
Xcode 4 crashed like crazy. It looks like they've finally stabilized it but I can't deny that the first 4 months after Xcode 4 was migraine inducing.
Yeah at first, but once you get used to the syntax and long method names, it's your standard static OOP language. Has some cool feature actually, like Blocks etc. Like it more then Java now.
Also what's really cool is, that you can seamlessly mix in C if you feel like low-level programming, I like that.
"you can seamlessly mix in C if you feel like low-level programming"
This is a huge plus. I've dropped to the C level on a number of occasions already in my projects. I also makes it MUCH easier to drop in existing C libraries for extra functionality since you don't have to write language bindings for it.
> Has some cool feature actually, like Blocks etc.
The blocks are kinda crummy though, and the verbosity is definitely verbose. `enumerateObjectsUsingBlock:` is a far cry from Smalltalk's `do:` (and its signature is awful too, even more so due to ObjC's lack of generics)
- No namespaces. Two letter prefix hack from the old C days
- Still makes use of a preprocessor
- Slow compilation times
- The way properties are declared just feels like an hack
- Automatic memory management extensions (GC & ARC) feel like an hack
- You need a Mac to properly learn it. gcc+GNUStep don't really count.
Namespaces would be nice, however I wouldn't drop the preprocessor; it's just too damn useful for code generation.
I haven't noticed slow compilation times. A 20MB codebase (big by iPhone standards) takes 40 seconds to clean compile on my mbp. (Xcode's indexing behaviors, on the other hand, leave MUCH to be desired).
Properties don't feel hacky to me; The @ syntax is a good compromise for preserving C compatibility while introducing more powerful constructs. Same goes for GC and ARC.
> You need a Mac to properly learn it. gcc+GNUStep don't really count.
Out of curiosity, why not? You don't get the Cocoa/Cocoa Touch APIs, but those frameworks are independent of the language itself. Relying on them is akin to saying you can't properly learn C++ without Qt, or Ruby without Ruby on Rails.
Cocoa and Cocoa Touch are integral to being paid for Obj-C, and they're by far the hardest part of it.
Learning objective-c, especially if you already know C, is pretty easy. The syntax is a bit weird but not hard, then you've got a few quirks and stuff, but fundamentally you can build a working model of the language in half a day tops if you're already a developer.
Understanding Apple's conventions (libraries, memory management, etc...) and merely knowing where to find the stuff you need in the doc, that's what take time. Cocoa is huge and is a complex beast, even if you don't dive into the C "Core*" stuff and remain at the NS/UI levels.
This sentiment is probably why there is such a proportionately low number of devs who take the time to learn Objective-C, which in turn makes those who do learn it even more valuable.
I really like Objective C, but I don't know that I would call it the most elegant. I agree it is an elegant solution to adding objects and messages to C (especially when compared to C++), but it is still an extension of another language, which makes it more pragmatic than elegant.
If you've never used an NSMutableURLRequest object before, but know how HttpRequests are made, you can figure out what's going on without having to dig into any documentation.
Many languages I've seen (C in particular) hide that explicitness. You call someFunction(arg1, arg2, arg3), but what do arg1, arg2, and arg3 do? Can you pass a 4th or 5th argument too? Unless you've memorized what someFunction() does, you have to dig into the docs, which makes the language harder to read. Obj-C method calls always list "every" available parameter, regardless if its used or not (e.g. nil).
------------------------------
Obj-C takes up a lot of horizontal screen space. It works best on high-resolution widescreen monitors, with a modern editor, and modern mouse, both supporting vertical AND horizontal scrolling. Limiting lines to 80 characters, or anything really, destroys its readability.
The most unreadable Obj-C code I've seen is usually formatted this way. Google's Obj-C code is a nightmare to read; they limit it to 80-characters (http://google-styleguide.googlecode.com/svn/trunk/objcguide....). Great for a 1980's terminal, not for modern 2560x1440 displays.
Frankly line-length should not be the job of the programmer writing the code, but of the IDE/Editor displaying it properly on-screen. When you say "all code must be 80 lines long", you've forced that upon every programmer regardless if it's a good decision or not.
It's like decoupling the Model and View. The Model is the actual code written, where the View is how it's displayed. Programmers should be able to customize how their View looks using their IDE/Editor. When you hard-code the View into the Model, you break decoupling, and force everyone to use the same View.
Most Editors/IDEs let you customize the view somewhat, like color-schemes and "wrap text". But I haven't seen a "complete" decoupling of the model (code) and view (how it's presented) yet, in any IDE/Editor. Someone please correct me if one exists. This is a feature I'd "LOVE" to see in all IDE/Editors and programming languages, as it will make verbose languages like Obj-C much easier to read based on the programmers preference.
This is more of a praise of Apple's naming conventions with the ios and Cocoa sdk's (which I agree are very good, as is auto-completion in XCode) than of Objective-C itself. Of course the quality of the framework is hugely important in how pleasant a language is to work with, but I wouldn't say that Objective C is an elegant language compared to everything else that's out there (IMO Python and Haskell are both very elegant, but there are a lot of languages I've never played with).
I agree about Google's styleguides... I used to code like that and line up all the :'s vertically, and i finally realized I was making my code harder to read.
So i refactored all my existing code to have every statement on one line. Yeah it's long, but my huge monitor and xcode in full screen remedies that.
Absolutely, I've been thinking this as well. But to make it really seamless, SVN/Git would have to work that way too, and they'd have to have knowledge of the language's syntax for that, which is not going to happen.
I've always seen it as an imitation Smalltalk but with segfaults. Does it have any advantages in expressiveness, rather than merely being native for two platforms some people are interested in?
Duh. Every single real language (not deliberately painful languages like brainfuck) makes PHP look terrible in comparison. That says nothing about objective C other than "it is not the worst language ever made".
Also, in general I don't buy into these methodologies where someone spends a few hours doing searches on internet boards for certain keywords as a way to estimate the number of people with various skills. It's not been shown to be a valid way of getting accurate data.