Hacker News Reader

Comment by tocomment | Hacker News Reader

Please save me from Objective C .... I hope this article isn't just a tease.

Objective C is a really interesting language and the Cocoa and UIKit frameworks are designed in a way that makes great use of the features of the language. Is there something like KVO (key-value-observing) available in .NET with the newer versions?

If you want to have fun driving a Ferrari, you better learn driving stick ;)

Coming from Python, any extra verbosity really drives me crazy. Declaring variables, and having to write the same thing in the header and implementation files hurts me. I could probably live with that though, I guess it's the memory management for iPhone development that really bothers me.

I think I'm just a high level programmer and I get bored/discouraged really fast if it takes too much work to make something happen on the screen/phone.

(Obviously C# really isn't that much better, but I was thinking .net on iPhone might lead to ironPython?)

My previous dablings into mobile app development were first with the old Palm OS (plain old C) and a bit of J2ME (oh the horror). Compared to that UIKit is bliss. I understand the python runtime is pretty compact. Thus I'd expect there to emerge solutions similar to what is currently done with C# code. Just wrapping the runtime in the app and having the code as resouces in the app bundle that get fed into the runtime when the application launches.

As someone who has done a minimal amount of Objective-C programming in the past, I have to agree. That being said, I've also heard a lot of hackers rave about it. I'm confused over why there's such a love/hate relationship with this language. Whats the story with Apple's dev environment being so Obj-C heavy? What's the chance they'll spring for it's replacement?

objective-c has a particular set of strengths that is well-suited to gui development. if you count its beginnings at next, it has been in use in this environment for over 20 years. there is no way in hell apple would abandon it now.

Apple inherited Obj-C in late 1996 when they decided on NextStep as the replacement for the aging Mac OS. (That purchase also brought in Steve Jobs as an "adviser" to CEO Gil Amelio... Six months later, Amelio and the executives that had made the Next decision were out and Jobs was running the show.)

At first Obj-C's future at Apple seemed far from certain. First there was a proposal to make the syntax more like C++, and later there was a strong push to switch to Java as the main language for the Cocoa API. Next's flagship product WebObjects (a Cocoa-based Web app server and framework) was rewritten in Java by the year 2000. Mac OS X still hadn't shipped, but Obj-C was not getting a place in the limelight as most of the new APIs were plain C (CoreFoundation, CoreAudio, new Carbon) to accomodate both old Mac developers and cross-platform developers.

Apple's Obj-C faith was gradually restored during this decade. The touted Cocoa-Java bridge did work, but there was a fairly fundamental "impedance mismatch" between Cocoa's API design and Java's static nature. Cocoa-Java was deprecated in Mac OS X 10.4, leaving Obj-C as the only native development language for Cocoa.

Carbon on the other hand kept growing up to 10.5, and it gained a lot of features that were effectively plain-C wrapped C++ implementations of Cocoa features (HIViews, NIB support). Clearly the notion of having to maintain these parallel APIs for GUI development didn't please decision makers at Apple, as 64-bit Carbon was pulled at the last minute from OS X 10.5, thus leaving Obj-C and Cocoa as the only game in Mac town for 64-bit GUI applications (which of course sent a clear signal that building new applications on Carbon isn't a good idea regardless of whether you need 64-bit support right now).

So why did Obj-C win? At least one thing that makes it a good fit for publishing OS-level APIs is that it's inherently late-bound and duck-typed. A Cocoa program can thus easily make use of new API features without having to explicitly link against the new version of the framework. (This is particularly important because Apple doesn't update their frameworks separately from the OS, unlike Microsoft with .NET.)

For example, if Mac OS X 10.3 added a -foo:bar: method to NSWindow, an application could easily check for the availability of this particular method while still maintaining compatibility with older operating systems, like this:

if ([window respondsToSelector:@selector(foo:bar:)]) { // do fancy 10.3 specific effects here }

Reply on news.ycombinator.com