I've heard people suggest this before, but Apple doesn't seem to feel the same way. Ruby (even MacRuby) is banned on the iPhone along with every other language that isn't C or Javascript. Apple plays things close to the chest, but banning a language that you intend to base the whole platform around just doesn't make sense.<p>Syracusa isn't wrong that Objective-C is getting long in the tooth, but Apple has shown more interest in incrementally improving Objective-C than replacing it.
> <i>The Dalvik virtual machine that ships with Android interprets byte code. A byte code interpreter has a few advantages over a stack that runs native code. Performance is not one of those advantages.</i><p>This is a cheap shot.<p>First of all, when building a JIT or a tracing compiler, it's always better to start with an efficient interpreter ... and for all intents and purposes, Android has a kickass interpreter.<p>Then you can add incremental improvements ... like JITing, or various tricks to optimize dynamic code paths. And this is where Android is today ... the latest version comes with a JITter that will only get better.<p>What an efficient VM truly allows is for regular programmers to write efficient code without thinking much about optimizations. So most applications can benefit from a good VM precisely in terms of performance.<p>I've also seen rewritten C++ apps in Java that ran faster, for many reasons, one of them being that you have the power to think about architectural optimizations without getting lost in little details.<p>And one other thing ... a mobile phone doesn't have the resources (like RAM) to shove in it too many optimizations, but on the other hand you can built specialized CPUs optimized for Android's bytecode.<p>If you do that, the "stack that runs native code" can eat your dust.
I dont see any concrete evidence that suggests Apples shift from Objective C in the linked article. Can you point to specific information that points to such a move. fyi pypy has a LLVM backend, as does haskell, I believe python is supported in Xcode too. Hence a similar article could have been written about Apple moving to python.
I can't really see Apple doing this, if for no other reason than Objective-C is something they can control, and Ruby isn't. If the core Ruby developers decide they want to add more features, change the language's underpinnings, etc. Apple's left to play catch-up. If Apple wants to add features, then they basically have to fork the language and hope their changes get merged in.<p>Apple's shown (and been shown) how much of a benefit it is to control your own destiny; even with Ruby being open-source, it's still an outside influence they have to work with or against. Objective-C, for all intents and purposes, is their language, one they can take in any direction they want.
This would be all kinds of awesome, but I think it's probably a dream. To leap from ObjC to Ruby would be a absolutely massive undertaking for them.<p>That said, they've pulled off crazier shit before.
I think there are two big reasons that Ruby isn't on the iPhone. For one, MacRuby is still in development and isn't stable yet. For another, the Objective-C GC isn't running on the iPhone, which is what MacRuby uses. As the project matures and the iPhone gets better hardware, I think Ruby will start to show up on it.
You really can't avoid native execution if you want to really push the frontiers on these devices. And because these are such small devices even lone developers can really push boundaries and make money and a name for themselves. But the second you start blindly "optimizing" their products, bad things happen in spades.<p>In my opinion implementing a VM purpose built for a specific language spec is, was, and ever shall be a mistake. Sun was wrong to do it with the original JVMs. In this regard at the very least Dalvik is ahead of the game. The problem of course is, however, that implementing any VM at all on an embedded device results in crap performance from all apps executing through it. The reason Apple chose to remove multitasking and force C# down people's throats was simply because it's the only way to develop an application that is sturdy and fast on an embedded device today. Claiming it frees the developer from having to optimize their code betrays your ignorance of developing on embedded devices.
Yes! This is so obvious to me. Why would they even bother with MacRuby if this wasn't the future of iOS development? What would bring more developers to iOS than a rapidly growing language that you can learn and apply to multiple platforms, and also to arguably the best web development environment out there? Objective C's message-passing is extremely compatible with Ruby. A high-performance, pre-installed, officially-supported Ruby implementation would be a huge edge over the drudgery of Java on the Android platform!<p>Yes, I am aware of Ruboto, but there is going to have to be some serious wrapping of the very extensive Android APIs to make them palatable to Ruby developers.
MacRuby apparently performs quite well, at least in this stage of its development. What would be really interesting is if this translates into real-world Rails/Sinatra/whatever performance gains significant enough to create demand for OS X hosting...
Unlike many of the other commentators, this seem feasible enough, given another year or so and some progress in terms of performance and the API.<p>I think it’d be great to have the option to write Mac apps in Ruby instead of in Obj-C, and it seems rather Apple-like to be the first to having a language like Ruby be a primary/supported system language. Wouldn’t mind seeing a Lisp there instead, but Ruby's a bit of the way there, at least!
If Apple cared about having a more friendly API language, they wouldn't have deprecated the Java bridge: [<a href="http://cocoadevcentral.com/articles/000024.php" rel="nofollow">http://cocoadevcentral.com/articles/000024.php</a>]<p>The only languages Apple has ever expressed a preference for are Pascal, C, Objective-C, C++, and JavaScript. Why would they add ruby when they already have JavaScript?
I believe Obj-C will always be what Apple build their API frameworks. But it is possible that MacRuby will be an option in future for programming on iOS like it is on Mac OSX.<p>When I heard of MacRuby, I had this immediate crazy thought that Apple choose Ruby to piss off Google :-) You know Apple vs Google and Ruby vs Python, and Google is basically a Python house.
They just took a big hit in the nerd press for banning twenty years' progress in programming language design. I think they want an iOS development process painful enough that only committed specialists (who double as evangelists) can manage to ship, because everyone else would tend to write portable code that runs on competing platforms.
This article seems very very speculative. For instance, I don't think the blocks implementation in ObjC is adequate as a <i>full</i> closure implementation. It certainly looks like Apple is trying to improve the language while continuing to remain "close to the metal" using C without the need for bridges.
I live in Cork, Ireland, location of Apple's European Corporate HQ, and I know from friends that they've been running Ruby on Rails courses there. It might be inconsequential, but you have to ask yourself why? ... it shows at least that they consider Ruby, and Rails to be significant in some way.
It seems extremely unlikely that Ruby will <i>displace</i> ObjC. I can imagine that it will become the blessed <i>scripting</i> language for the Mac, in something like the way that Visual Basic has been for Windows.<p>Either way I'm glad to see Apple's support behind Ruby.