Hacker News Reader

Comment by allenbrunson | Hacker News Reader

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.

View on HN

John Siracusa wrote about this very aptly 5 years ago: Avoiding Copland 2010 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-revis...

And then he talked about it 2 weeks ago in the Hypercritical Podcast: 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.

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

It'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.

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

I agree with the potential in those 3 things, but consider...

Saving even an hour writing something as a few terse lines means nothing if in 6 months you need days to decipher and debug it. The code has to remain clear somehow. About the only acceptable use of a clever one-liner is when it provably reduces the runtime of the generated machine code by a significant amount...and even then, the hour you saved not writing code had better be spent writing a block of comments to explain your one-liner.

Yes, Objective-C is weird. But put yourself in the seat of a language parser; it's already a very difficult problem to ensure that some languages parse correctly and unambiguously. If you introduce new syntax that is "weird", it's actually safer than doing something that may cause subtle incompatibilities with all the code that's been compiled a certain way for decades. And that code has proven the "weird" language is practical, whereas a brand new language (no matter how perfectly designed it seems to be) may actually have parser corner cases that have not been ironed out yet.

Garbage collection is a benefit in many situations, but Apple has managed to create a very responsive phone where mere milliseconds are just perceptible enough to make a user think "my iPhone feels fast, and this other phone feels slow". Right now, performance matters most, and manual memory management is an edge for Apple. It's important to make programmers happy, but not as important as it is to sell things to users.

I thought the block syntax was an extension of C, not a part of Obj-C/Cocoa runtime.

Timing is everything. That epiphany has not yet lead to what it promised originally: a consumer OS in managed code, with major applications in C#.

I do not think that will happen soon, either. => Apple will probably be fine with a OS written in C with some added functionality, especially if they manage to build one or more managed environments on top of it. That way, companies can build their in-house stuff in managed languages, while the core stuff remains finely tuned C.

I do not think that is the most beautiful solution, but it may well be the pragmatic approach that wins the race.

that'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.

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

Well 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-s...

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

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

It's rather sad that Apple Dylan went nowhere. It would have been a terrific language to pair with Cocoa.

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

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

Well, 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.

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

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

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

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

AFAIK MacRuby already works in this way, using the existing (Obj-C) Cocoa frameworks in conjunction with the MacRuby runtime.

Reply on news.ycombinator.com