[reidmain]

What about it makes it painful?

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.

[whatthefish]

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.

[masklinn]

> What about it makes it painful?

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.

[reidmain]

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.

[alextgordon]

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

[tarkin2]

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.

[reidmain]

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.

[aaronbrethorst]

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.

See Apple's docs for more information: http://developer.apple.com/library/mac/#releasenotes/Objecti...

[tarkin2]

Thanks a lot. I'll take a look into that. Pity that you still need to nil the objects before they're garbage collected.