Hacker News Reader

Comment by AndrewO | Hacker News Reader

Apple is fortunate that they're the only ones they have to check with to change 3.3.1. When the hardware has gotten ample and the software is mature enough, I for one won't be surprised if we see revisions.

Meanwhile, a blanket ban will accomplish their goals just fine (take your choice: blocking Adobe, preventing fragmentation, making developers choose single platforms, etc).

View on HN

They could change 3.3.1, but they didn't have to blanket-ban Ruby to begin with — they made already have four languages they allow. The fact that Ruby was banned shows that they don't even place it on a level with C++, much less Objective-C.

On top of that, MacRuby was just starting efforts to target the iPhone when Apple banned it, leading the developers to throw their hands in the air and say, "Oh well, didn't really get far anyway." If Apple really wants Ruby on the iPhone, stopping its own people from working on the project doesn't make any sense.

Yes, they did have to blanket-ban it to begin with. If they're to make an exception for this, then in the interest of avoiding fragmentation they won't be making an exception for the Ruby language in the abstract; rather they'll be making the exception for the MacRuby implementation in particular. MacRuby is a unique implementation, and programming Cocoa through MacRuby is vastly different (and incompatible) experience from programming Cocoa on other OS X Ruby implementations.

Given that MacRuby is not considered "stable" just yet, the time is not right for Apple to provide an exception to 3.3.1 for Ruby programming. If this does happen, then it will happen only after MacRuby is good and ready.

I emphasize that I do not support Apple's draconian policies toward iOS developers, but their behavior here is internally consistent with the possibility of an eventual allowance for MacRuby.

I don't know about "not considered stable." The official MacRuby site claims the current version is "Stable for Cocoa Development." It's not on the iPhone, granted, but that's because it's banned, so nobody wants to waste time on it.

The MacRuby team reckons it's "stable", in the sense that the API shouldn't change too much in the future and it probably won't crash. But there are good reasons Steve might not yet consider it mature enough for the iPhone. For one thing, gems don't work yet.

MacRuby is not on the iPhone because there is no garbage collected Objective-C runtime on the iPhone, NOT because it is banned.

Not so. The MacRuby team had already thought up a number of ideas for working around the lack of a garbage collected runtime (the most promising was similar to the direction Apple's going with Objective-C, where retain and release happen automatically based on policies). They never got implemented because Apple instituted the ban on programming languages right around the same time.

The ban is on using language implementations that don't ship either as compilers with the dev tools (C, Obj-C, C++) or as runtimes on the device (JS) without prior approval (plenty of people embed Lua, and Unity3D apps still get approved).

Apple is obviously planning to ship MacRuby with a future release of Mac OS X as a fully supported language implementation, possibly with 10.7 in 6-12 months. Perhaps they will do the same with iOS, but they've had other priorities.

Just remember that we're talking about a company that managed to migrate its entire product line to an entirely new processor with few people (inside and outside the company) really knowing until they unveiled the first demo machines.

Compared to that, adding a new programming language (that doesn't even affect their existing 3rd party applications) to a platform they own completely is child's play.

To be fair, NeXTStep very publicly run on x86 before NeXT was bought by Apple -- it didn't just appear out of nowhere. And the actual processor is mostly abstracted away -- it's not difficult to simply recompile your apps for another CPU.

Not just the PPC -> Intel switch, before that they switched from 680x0/m68k/68k/68K to PPC as well. Which certainly wasn't just a simple recompile.

http://en.wikipedia.org/wiki/Apple_A4#History

I think we're talking past each other. All of your comments seem to be arguing that Apple could do this if it wanted to, while all of my posts are arguing that Apple hasn't shown any desire to do this.

AndrewO's comments seem to be arguing that Apple has made even more drastic changes in the past without publicly showing any desire to make the change until shortly before doing so.

Reply on news.ycombinator.com