3 ms·

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 i

by streblo 18y ago

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?

allenbrunson 18y ago
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.
pavlov 18y ago
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 }

by streblo 18y ago

allenbrunson 18y ago

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.

pavlov 18y ago

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 }