Rarest language? Objective-C has highest job posting to developer activity ratio
generalassemb.ly
generalassemb.ly
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.
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.
Mac desktop apps too! ;)
...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.
Android lost 13% US market share in Oct. and Nov. to the iPhone (cnn.com)
Numbers for total market share here: http://www.macrumors.com/2011/12/29/apple-and-android-gain-s...
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 :-)
Does that pretty much explain it?
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.
They also don't realize how insanely expensive it is.
"I want a mobile app. That's like $500 bucks, right?" - Client
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.
As a disclaimer objective c is my language of choice, my plan this year is to make the code portable.
Some info here: http://www.cocos2d-iphone.org/forum/topic/25414
Take the surplus of enthusiasm for Ruby, combine it with the high demand for iOS developers, and there you have it!
Now if only Apple would make MacRuby a first-class language for developing iOS apps...
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.
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.
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.
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.
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.
What do devs at HN think? Does it make sense to think the market for Obj C talent is going to last?
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.
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.
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.
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. 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.
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.
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.
I cringe now when I write PHP.
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".
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:60.0];
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.
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.
Also what's really cool is, that you can seamlessly mix in C if you feel like low-level programming, I like that.
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.
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)
blocks are closures and they have some semantics like function pointers.
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.
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.
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.