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.
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.
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).
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.
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.
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.
Also, it seems a bit ironic for whoever is developing MacRuby. You're donating labor to a company that gives nothing away for free or even cheap. Then they ban you. Makes you think ... perhaps you should target Ubuntu next time...
Stating that Apple 'gives nothing away for free' is quite hyperbolic. Apple certainly contribute to open source in more ways than you're giving them credit.
> 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.
This is a cheap shot.
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.
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.
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.
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.
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.
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.
Just because they "sponsor" MacRuby doesn't mean they favor ruby as a replacement for Objective-C. Until ruby is as fast as Objective-C, I see no reason they would make such a change. Low performance languages have never gained serious adoption on embedded platforms, which includes everything that has made Apple, Inc (not Computer) successful.
Maybe I'm a non-believer, but I also don't see any benefit to Apple supporting ruby specifically. If they were to have a higher-than-objc level API, I expect it to be an LLVM API which would be compatible with languages with an LLVM backend.
Measuring and comparing the "fastness" of a language is a tricky thing in general, but I think it is safe to say that for most intents an purposes we can consider MacRuby just as fast as Objective-C. The point you seem to be missing is that both run on top of the same runtime and both use the same foundational classes. So the same operation performed on a MacRuby String and Objective-C NSString should take exactly the same amount of time.
The only thing that prevents MacRuby from being fully compatible with Apple's "embedded platforms" is the lack of garbage collector on said platforms. By the time MacRuby is sufficiently stable and optimized Apple's portable devices will be capable of comfortably running memory managed code.
As for the "LLVM API", for one, I don't really understand how is that supposed to work - there is no "native" LLVM language and so on; for two, such an API will be lower-than-objc, not higher; and for three, reimplementing Cocoa and CocoaTouch as some new supposedly more abstract (whatever that's supposed to mean) API is going to be a monumental and almost certainly very disruptive task - and all of it for no good reason.
A lot of the comments, I'd say yours included, seem to be coming from the presumption that Apple's adoption of a higher level than Objective-C language is inevitably going to be a huge overnight change. But the beauty and genius of MacRuby is precisely that it does not require a huge overnight change. You can mix and match Ruby and Objective-C as you need or like. You can write high level, terse code using the HotCocoa wrapper or you can fall down to the nitty-gritty OS X C APIs, for a good number of which there are MacRuby bindings.
Btw, Apple is not "sponsoring" MacRuby. Apple is developing MacRuby, it's an Apple project. Will it replace Obj-C? Probably not. Will it become a blessed alternative? Everything seems to point in that direction.
Could not agree more. MacRuby exists, it's great. Use it. Who cares whether or not it will replace or complement Obj-C, sliced bread or even the internal combustion engine. GC is the key to the iOS port. Not there yet, so no option at the moment. Of course the future (maybe distant, maybe near) will bring GC to iOS and MacRuby with it. No need for reinventing the wheel.
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.
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.
MacRuby is a fork of the language, albeit a friendly one. Just as Rubinius, JRuby, IronRuby, and others are all forks.
I can see Apple replacing Applescript with Ruby, but just based on the fact that MacRuby uses the ObjectiveC runtime, I doubt it's really going anywhere.
Not at all. Given that they're both dynamic programming languages with runtime dispatch, there's really little impedance mismatch between Ruby and Objective-C. Thus MacRuby, a Ruby implementation that encapsulates Objective-C objects and messages in Ruby objects and methods. Cocoa in Ruby without a bridge -- it's already there, it's a done deal.
Now as for whether they'd replace Objective-C with MacRuby, no, that wouldn't make sense. The two would live side by side. Apple can continue to implement Cocoa frameworks and core applications in Objective-C while also offering an excellent Ruby programming environment built on top of that.
It's sort of like C# vs. F# or IronPython in the .NET world -- Microsoft didn't have to replace the base .NET assembly implementation language (a.k.a. "assembly language for CLR") in order to provide more attractive dynamic or functional languages on top of the same infrastructure.
EDIT: In fact, the semantic mismatch between Objective-C and dynamic languages like Ruby is less than the mismatch between dynamic languages and the CLR, which mirrors the statically-typed semantics of C#. Is Apple's combination of the Objective-C type and dispatch systems and LLVM going to one-up .NET from a direction that we didn't see coming?
Having used both Objective-C and .NET, I would much rather be faced with implementing a dynamic language atop .NET than have to do so atop Objective-C. While ObjC's dispatch system is quite dynamic, the relative weakness of the type system (if you can even call what ObjC has a 'type' system) and the amount of C baggage it drags along with it makes it a rather unfriendly environment for running dynamic code.
Here's one example: With the .NET type system, you can check a set of arguments against the signature of a method defined in the type information of an object instance, which means that you can be absolutely certain that your invocation will succeed without corrupting state or returning incorrect results. What's more, you can do this check at compile time (in a static language, like C#) or at run time, via reflection. The .NET JIT and runtime code generation facilities mean that you can do 'static' verification at load time for scripts instead of at the point of every invocation. In cases where you have a mismatch between the types requested and the types provided, you get clear, precise error feedback that allows the problem to be corrected. The .NET runtime is able to use this type system to perform a large number of useful safety checks against all code when it's first loaded, so that in many cases it can guarantee no memory corruption or out-of-bounds accesses will occur without having to check every single operation.
As the vast majority of Objective C invocations in a Cocoa application are effectively static (you're sending a message, as described in the Apple documentation, to an object of a given interface, as described in the Apple documentation, which you constructed following instructions in the Apple documentation), the dynamic nature of ObjC invocation wins you very little. The ObjC type system cannot provide you much assistance for those invocations, because it's built atop the C type system - GCC will check your argument types for you statically at compile time, but at run time, given an arbitrary ObjC object, it's going to be quite difficult to be certain that an invocation will succeed. What's more, in most cases GCC can provide no more than warnings, and those warnings are often incorrect.
On the other hand, for the vast majority of code written in a language like Ruby or Python, your method signatures contain no type information, so no validation can be performed. Neither Objective C or .NET win here because both require strong types for arguments. You need only look at NSArray to see how little you win by using Objective C in this case.
Ultimately, in both cases, neither environment is a good fit for a language like Ruby, but I would argue that .NET (and, for similar reasons, the JVM) provides a far stronger foundation upon which to build a language like Ruby. Building a language like Ruby on top of Objective C is only superior to building it in C due to its status as Apple's preferred language for OS X development.
I would argue the Smalltalk-esque message-passing system is an advantage, not a weakness. A large amount of the dynamic nature of languages like MacRuby can be captured with such a system whereas on .NET you need another abstraction layer (like the Dynamic Language Runtime), leaks and all.
And I would nitpick the argument that Objective-C requires types for arguments. You can declare arguments as "id" in Objective-C, exercising message passing, and objects will respond to the messages regardless of type. This is why MacRuby and Objective-C are a good fit: both languages are based messages, a concept alien to .NET.
MacRuby has already reimplemented most of Ruby's classes on top of equivalent Cocoa ones (String < NSString, Hash < NSDictionary, Array < NSArray). That removes a big part of bridging problem that existed with things like RubyCocoa.
Not to mention the ability to call existing APIs and the fact that C and MacRuby will both be running on LLVM—I think it's less crazy than it appears.
It's not really that crazy. Take a look at MacRuby — it's pretty close already. Apple just doesn't seem to have enough interest to replace Objective-C.
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.
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.
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...
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!
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.
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.
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!
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?
Once upon a time Java was a "co-equal" with its own colored box. But Apple's been pretty mercurial when it comes to languages: Clascal, Object Pascal, AppleScript, ScriptX, SK8, NewtonScript, HyperTalk, Dylan, MCL, {AppleSoft|Integer|Mac} Basic, Smalltalk, Java, Corba IDL... most of those are way more friendly than Java, but died just like desktop Java. MacRuby's a little different, I'm guessing it's a research project to see what might be compelling about a unified, llvm-based, multiple-language runtime.
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.
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 full 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.
indeed. especially as people inside apple have already built web apps using RoR in the past. one that comes to mind is the application they use for enterprise managing lots of iphones (i can no longer find it, but i assume it's still around)
It seems extremely unlikely that Ruby will displace ObjC. I can imagine that it will become the blessed scripting language for the Mac, in something like the way that Visual Basic has been for Windows.
Either way I'm glad to see Apple's support behind Ruby.
No, that's probably wrong. With MacRuby, bridging is toll-free, and, as others have noted already, there is a much lower impedance mismatch between ruby and objective c than there was between java and objective c. Apple has improved the support for scripting languages over the years with the introduction of the scriptingbridge framework. These days, you can easily write an app on the mac in either ruby or python, the only constraint is that things become a mess if ever raw c structs are exposed by the cocoa api (and yes, there are still a few places where this is the case), or worse still when there is no cocoa api for a particular framework. Still, even in these cases there us some support in the scripting bridge framework, although my personal preference for this type of problem is just to wrap the c code in an objective c wrapper class before using the wrapper class from within MacRuby. Works like a charm!
Unlike (I suspect) a lot of people here I don't mind Objective-C and I really dislike Ruby.
Would this effect my decision as to whether I develop for the iOS/OSX platform. No of course not.
At the end of the day I actually dislike all languages, just to varying degrees. Python is the one I dislike the least. As soon as I can get my programming job done without the need for programming I will do it.
The original interpreter is already replaced with YARV in 1.9. But yes, MacRuby replaces YARV with an LLVM-based virtual machine. (Only passes about 85% of RubySpec right now, though.)
Incidentally, Rubinius is also based on LLVM these days.
Such a fundamental changes like unladen swallow in python or migrating to LLVM-based VM in ruby must be backed by very powerful and resourceful entity. Good news!
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.