neontology

What was your impetus for writing RubyObjC after clearly investing a lot of time in the RubyCocoa community? Was there a particular technical direction you wanted to take that the RubyCocoa maintainers weren’t comfortable with, for example?

At C4, I presented my opinion that Objective-C is a great platform for building high-performing dynamically bindable components. That’s an important and generally overlooked feature, and it has made me a big fan of Objective-C. But Objective-C also has some significant inadequacies that could be fixed with another language layer—the same way that Objective-C improves on C and C improves on assembly language. Last year, I made a serious effort to use Ruby as that language.

For the first part of the year, that effort focused on RubyCocoa, which had been written five years earlier as a hobby project. I say “hobby” because it appeared that in its five year life, no one had successfully used RubyCocoa to write a serious application, not even its author. But if used carefully, it made for some interesting demos, and overall, Ruby seemed to be a better semantic match to Objective-C than its main alternative, Python. To prove it, I focused on creating documentation and significant examples, culminating in the console that I published last year in August. That helped debug RubyCocoa and also seemed to generate a lot of interest in using Ruby to write Cocoa apps.

I started RubyObjC in September 2006, right after Apple’s WWDC. There, Apple announced that they were making a big push into RubyCocoa with the goal of making Ruby a viable language for application development on Leopard. This included shipping supported versions of the RubyCocoa and PyObjC bridges with Leopard. Our first difference was over Ruby’s place in the tool chain. I wasn’t so interested in 100% Ruby apps; for my projects, I wanted a glue language that was simple, stable, and fast. Apple’s goal was broader and called for more change (churn) in the RubyCocoa code base. Bug fixes and performance improvements were less important, because to Apple, the release date that mattered was Leopard’s. So rather than bump into all the changes Apple was making, I decided to start working directly with the Objective-C runtime. That led to a completely new bridge, RubyObjC.

I think that RubyObjC makes the bridging process clearer; it includes Ruby interfaces to all the major elements of the ObjC runtime. Because I had no interest in writing 100% Ruby apps, I emphasized speed and stability first. In my experience with it, I was able to write things in RubyObjC that I could not get working in RubyCocoa. Since then, Laurent Sansonetti at Apple has fixed a lot of bugs in RubyCocoa and has even pulled in a few ideas from RubyObjC, but I haven’t used RubyCocoa since October 2006. That’s when RubyObjC became viable enough for me to switch all of my examples and projects over, and I haven’t needed to go back.

Are the two projects competitors, complimentary, or serving different purposes altogether? If they’re competitors, would you recommend RubyObjC over RubyCocoa to someone getting started with Ruby Cocoa development? Why or why not?

For me, they were competitors. I stopped using RubyCocoa once I had RubyObjC, and when I did, my work started moving a lot faster. I don’t have a lot of time to spend supporting RubyObjC, so if you want support (from Apple), it’s best to use RubyCocoa. But if you want an open toolkit for bridging Ruby and ObjC, RubyObjC is worth a look. It’s now on RubyForge and released under the Ruby license. Maybe it’s because I wrote it, but I think that RubyObjC is much easier to read and maintain. And since I started in September and had a working bridge in October, how complex could it be?

Have you had any communication with Apple regarding the place of Ruby in their development hierarchy? Do you know if RubyCocoa and/or RubyObjC will ship with Leopard?

My RubyCocoa web site gets a lot of hits from Apple, but I haven’t had much contact with people there. Last year I had a promising conversation with someone who abruptly disappeared on me; I hear that’s a common experience. But I now know Laurent Sansonetti fairly well (and even gave him an early preview of Nu). Laurent is in charge of getting RubyCocoa ready to be included in the Leopard release. He’s been doing a great job at this; my decisions have been in no way related to his work.

Do you think it’s feasible to develop a Cocoa application in pure Ruby that’s indistinguishable from its Objective-C counterparts? Could an application with a lot of Mac-like polish (ex: Transmit, MarsEdit, OmniFocus) be written in Ruby, or are there certain areas of Cocoa development that are off-limits to RubyCocoa/ObjC?

As I understand it, that’s Apple’s goal. So the answer is eventually, maybe, yes. It might be worth a try for an indie developer, but I wouldn’t bet anyone else’s money on it yet. Regardless, you owe it to yourself and your users to spend some time reading the source code for any bridge or glue language you use professionally. You don’t want to wait until something breaks.

With Ruby, Python, and other established scripting languages, even the best bridges come with some serious challenges that counter their advantages. You can make them work, but that doesn’t mean there isn’t a better way. For example, F-Script is much better integrated with Objective-C than Ruby or Python ever will be. And then there’s my other project, Nu.