5 ms·
I've been using objective-c since 2001, when I made the switch from BeOS to Mac OS X. It's not horrible. I don't have any real problems with it. But I think its
by allenbrunson 15y ago
I've been using objective-c since 2001, when I made the switch from BeOS to Mac OS X. It's not horrible. I don't have any real problems with it. But I think its replacement is long overdue.
Given that Apple has a long history of ditching huge swaths of its technology in favor of more modern alternatives, no matter if their userbase screams bloody murder or not, I'm surprised it hasn't happened already. This would be a good project for those billions they've got sitting in the bank.
I think it would be great if they would anoint some successor as their new systems language, then port Cocoa to it. Programmers could use either objective-c or the new systems language for a few years, just as we used to decide between Cocoa and Carbon. Then objective-c could gradually fade into the past.
- protomyth 15y agoThey did try to replace Objective-c with Java and that showed a lot of areas where a framework built for a dynamic language fails on a static language. I think Objective-C is a decent tradeoff of C and Smalltalk. I like the selector syntax as opposed to the C++ syntax.
- allenbrunson 15y agoThey didn't actually try to 'replace' objective-c with java, though. It was just an alternative. In the early days of Mac OS X, many programmers were seduced by it, but they complained loud and long about having to learn this weird new language that had practically no adoption outside Apple. My guess is that Apple decided to give them java to quell the complaining. It wasn't adopted widely, so that was that. What they should be replacing objective-c with is something that looks more like, say, Python.
- msbarnett 15y agoWell, Apple has been funding a lot of the development of MacRuby, possibly as an exploration of what it would take to anoint a popular scripting languages as a "nicer" alternative to Objective-C.
- smackay 15y agoThe big push for Java was with WebObjects and Apple's half-hearted push into enterprise systems. Initially Apple's version of Java (they wanted tight integration with Cocoa) was always a couple of revisions behind Sun's so that was always a source of frsutration with developers. With the new focus on consumer devices the enterprise space was left to wither and Java with it. Anything that is going to replace Objective-C must be at least as fast - Apples really cares about the customer experience not the developer experience.
- gcv 15y agoIt's rather sad that Apple Dylan went nowhere. It would have been a terrific language to pair with Cocoa.
- cubicle67 15y agothat's fine, but what would they replace it with? Java? C#? not likely. C/C++? well, you can use them already I think MacRuby is the closest we have atm to something being groomed as a successor to Obj-C. It's got a way to go yet, but it's already at the stage where it's viable for smaller projects and there's a (small) number of MacRuby apps available on the OSX app store.
- noarchy 15y agoAny idea how much investment is taking place in MacRuby? If they're really interested in grooming a successor, I'd figure that there would be some serious work going on, behind the scenes. With the success of the platforms on which Obj-C is used, I don't know if a successor will be another language. An update to Obj-C itself might make perfect sense.
- danieldk 15y agoWell apparently, MacRuby is already a private framework in Lion, so it serves some purpose in the eyes of Apple. http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-share/ http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-s...
- danieldk 15y agoI agree that MacRuby is the most likely 'successor' (or rather, alternative). Another advantage of MacRuby over some other 'scripting languages' is that it can be compiled to an executable via LLVM bytecode (per macrubyc). This will be appealing to anyone who doesn't want to give away his/her source code.
- jaes 15y agowhy not just smalltalk? or f-script with inline C? either of these would really just be a more convenient syntax for most of the higher level code written now anyway (given my experience). the runtime is sufficiently flexible that a simple change in syntax with a friendlier IDE would get many people raving about how great the platform is in much the same way as those experienced with it do now.
- patrickgzill 15y agoCorrect me if I am wrong, but there is a huge amount of Obj-C in the guts of OSX. Replacing it with another language would require a large RAM footprint as both older apps and new apps would require a large amount of shared libs to be loaded, for possibly not that much additional benefit.
- allenbrunson 15y agoI am very far from an expert at Mac OS X system internals, but I don't think objective-c is all that ingrained in the kernel. You write device drivers in a restricted subset of C++, as one example. userspace Mac and iOS programs have to link to an obj-c runtime library, but it's not much more onerous than linking to, say, libc or libc++. The big hit would be that, yes, there are gigabytes of objective-c frameworks installed, which would presumably have to be replicated in the new language. But I could see Apple finding a way to sidestep that issue. Maybe the new systems language and objc could both compile down to similar binaries. Painful or not, it's going to have to happen sooner or later. Objective-c is, in my opinion, the most outdated thing in Apple's technology stack. There will come a time when it is as big an albatross around their neck as Mac OS 9 was, which they waited far too long to replace.
- mambodog 15y agoAFAIK MacRuby already works in this way, using the existing (Obj-C) Cocoa frameworks in conjunction with the MacRuby runtime.
- Entlin 15y agoJohn Siracusa wrote about this very aptly 5 years ago: Avoiding Copland 2010 http://arstechnica.com/staff/fatbits/2005/09/1372.ars http://arstechnica.com/staff/fatbits/2005/09/1372.ars Then he revisited it 10 months in 2010: http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars http://arstechnica.com/apple/news/2010/06/copland-2010-revis... And then he talked about it 2 weeks ago in the Hypercritical Podcast: http://5by5.tv/hypercritical/14 http://5by5.tv/hypercritical/14 Abstract: new language and new API go hand in hand. A memory managed combo trades execution speed for faster program creation. Was already needed 5 years ago. The recent garbage collection additions don't cut it. Microsoft started working on their successor (.net) 10 years ago and now it's starting to look good. Apple gained some leeway when the iPhone happened. With ever improving CPUs on mobile devices, Apple still risks losing ground down the line. Great podcast episode, I highly recommend it.
- ryannielsen 15y agoYou could also argue that, given the current success of iOS and Mac, Cocoa isn't a significant hinderance to Apple's platform's success. (Not to say I wouldn't mind some significant advancements in Apple's preferred runtime, but there's strong evidence that the current runtime is actually quite suitable. If, as you say, .NET is only now starting to look good after a decade's worth of work, perhaps that wasn't the wisest investment on MS's part. Siracusa's been beating this drum for years and, like many of his crusades, I struggle to see how Apple suffers from not following his advice.)
- makecheck 15y agoIt's fine to push for a better language, but so far you seem to be saying we should do it just because the current language is too old. What are specific things that are wrong with the language Objective-C 2.0 (and not just Cocoa, which is an API; and not just Mac OS X or iOS, which are platforms)? Why should Objective-C not just evolve into something a bit more interesting? And when considering any alternative, what are the most costly considerations for any developer, including Apple? The size of a code base is a significant factor. The fact that established code already works (new code may add bugs) is a significant factor. The wealth of knowledge already accumulated by programmers is a significant factor. A new language is very unlikely to win a war in those areas, so it would almost have to solve some other problem that is still costing developers a lot because they're using today's languages.
- allenbrunson 15y agoGood question! I can think of a lot of reasons why Apple should switch to a more modern systems programming language. We have all read pg's essays where he extols the virtues of Lisp, compared to other languages. His primary argument, as best as I can tell, is you can write programs with far less code than in other languages. Such an advantage would be a big win for the platform, and we may come to a time when Apple is forced to do it, because everybody else has, and they risk being left behind. Objective-C is becoming a weird frankenlanguage. It already was, arguably: a thin layer of smalltalk-like OO sitting on top of C. Just recently, Apple added blocks, which are like continuations in other languages. Maybe that's a good thing, but I think it would be a better thing if we went with a language that had those types of concepts from the beginning. It has been mentioned elsewhere in this thread that Microsoft has already had their platform-two-dot-oh epiphany, which was .Net: managed languages with automatic garbage collection, and so on. If this evolves into a big win for programmers, Apple will be forced to follow suit. The biggest argument I can think of for Apple not to try a new systems language is that their cash cow right now is the iOS platform. Doing this now would no doubt cause serious memory and CPU pressure on small devices which can't afford it. So knowing Apple, their likely answer to that would be to come out with a new generation of devices that are no longer compatible with objc, which you have to rewrite everything for.
- mhd 15y agoIt took years to get (mostly) rid of Carbon. Heck, Cocoa still has the NextStep prefix. The amount of change Apple is willing to make can be hugely exaggerated, especially if they're able to control the respective technology (which they do mostly, one noticeable exception being desktop CPUs and GPUs).