[msbarnett]

Seems unlikely. It's always been possible to create Mac apps in, say, C++ using Carbon or Qt, but ObjC/Cocoa has remained very popular despite that.

It's an exceptionally good and low friction framework that people tend to like. Most of the anti-Objective-C sentiment seems to come from people offended at the notion that they might be required to learn something new rather than stay forever in their comfort zone.

[mkramlich]

I think a lot of the complaints about having to use ObjC come from folks that (a) find it inferior to one or more languages they already know (Python, Ruby, etc.) and/or (b) feel it is somewhat of a platform ghetto (effectively only used on iOS and Mac) and therefore not as efficient use of one's time investment as another language and stack that you can use on many other platforms, and for many other types of applications.

The biggest problem with Objective-C, in my opinion, is that the syntax and philosophy is a step backwards in time in terms of programmer friendliness. It is so much more verbose and clunky compared to Python, for example. Use Python's built-in dictionary type a while, then be forced to use Objective-C's dictionaries. Yikes. Then the memory model is more complex and more prone to error due to inconsistent lifecyles and naming conventions. The XCode/iOS project model, build generation and signing crud is just nasty compared to how you can develop and deliver web apps to production in, say, Python, or even desktop apps. It's just a nasty and overly complicated rat's nest of special cases. I counted once and an iPhone app has something like 8+ different names or identifiers, each used in subtly different ways in different places, just asking for confusion and conflict. I ship a desktop app or web app and I have effectively one or two identities to deal with, and no Apple hoop-jumping to do, no publication delays, no long silly list of things I can and cannot do, etc.: heaven in comparison.

And no it's not about learning something new. I'm personally on like my 8th language used professionally, and love learning new things. But sometimes "new" things are worse than what you already know. In that case, learning that new thing is bad, and a poor use of your time. I've learned enough Objective-C to be productive, but also enough to know it's a step backward from some other tools in my toolbox, so bad use of my time in an ideal world. I'm thrilled about Apple's change today because it raises hope I might be able to use a sexier language than ObjC/C/C++.

[pornel]

I generally agree, but: verbosity is mostly due to Cocoa naming conventions, not Objective-C. PyObjC (Cocoa bridge for Python) is — aside from few classes mapped to Python types — equally verbose and even more annoying to use, because you can't mix method name with arguments.

Reference-counted memory management might be step back, but I don't agree about inconsistent object lifetimes. Cocoa has simple rules: you're responsible for releasing objects returned by methods with `init`, `new` or `copy` in name. delegates are not retained. Everything else is retained and autoreleased for you. It's pretty consistent and even clang's static analyzer can catch common mistakes.

[msbarnett]

Eh, a lot of the complaints just strike me as not understanding a tool in terms of its context; Objective-C is, intentionally, a strict superset of C, so it carries a lot of baggage in order to not break C code. It predates most of what we now think of as C++. It managed to bring Smalltalk-style dynamic messaging to C in a manner that wasn't insanely slow and didn't depend on heavy-weight virtual machines.

Are Python's dictionaries syntactically a bit cleaner? Sure. But Python is much newer and had the advantage of not having to maintain compatibility with a vast corpus of C code, and not having to care about achieving very very very good native code run-time performance on very resource limited machines.

It's just a tool. One that makes a completely different set of tradeoffs than, say, Python (Python might win in terms of cleanliness of dictionary syntax, but it's orders of magnitude less suitable for bringing high-level, dynamic OO to low-resource programming). The people who whine that these Apples aren't Oranges and that they refuse to do work in anything that isn't citrus-flavoured strike me as having come to rely too heavily on familiar crutches to truly learn to appreciate the other advantages that can be found in tools that make different trade-offs.

[mkramlich]

I understand and agree with much of what you say. However I am -- increasingly as I get older -- a fan of Getting Things Done, so I prefer tools that let me do that better. This is the role where ObjC is inferior to alternatives like Python, among others.

I was doing assembly programming in the mid/late 80's, then was a C programmer for about 5 years, then C++ for about 2, then Java for many years after that before switching to Python as my default goto language. Leaving out experience with several other languages. I am a language geek, not super hardcore as some, but far above average. So I'm quite confident in saying ObjC is a needlessly archaic, verbose and complex language compared to alternatives. Is it totally without merits? Of course not. Was it designed to fit a niche and context? Yes, and perhaps it achieved those goals well, and some would argue better than C++. But all of this is irrelevant when it exists as part of a larger set of choices available to a modern programmer who wants to Get Something Done and has sufficient freedom to choose his tech mix. Given the right permutation of constraints any tech can become the Perfect Choice for those constraints, so saying that alone about ObjC is not a compliment.

[gte910h]

<-- I do apps fulltime

Objective-C isn't bad, as I like both C and Smalltalk, it seemed quite normal to me.

I will say the lack of a persistent ORM that isn't as complicated as removing an internal organ is a bit of a liability (simple, core data is not).

And yeah yeah, persistent object graph blah blah.