There are many more development tools that we can make for ourselves with Ruby and Cocoa. If you need inspiration, just look at some of the things that have been done for more mature bridges like F-Script and PyObjC.

But we can also go places where other languages haven’t been. Like more DSLs for higher-level structures and design patterns (like bindings). Like layout helpers to dynamically place objects according to Apple’s User Experience Guidelines. Like mixing Ruby libraries into Cocoa applications to parse XML or generate code with erb. With Ruby and Cocoa we can build what we need as we go.

For the last year and a half, I’ve been using the Objective-C/Cocoa combination and Ruby and Rails. It has been interesting to see the parallels and differences between the two frameworks and cultures. I’ve noticed one thing worth mentioning here. With all the work that has been done by the Rails community, no one has written an Interface Builder for Ruby on Rails.

It has a lot of other things: database wrappers, templating engines for HTML and javascript, controllers that map HTTP queries to actions, test harnesses, plugin frameworks, deployment systems, servers, and countless innovations on the theme of web application infrastructure. But there’s no graphical tool for designing user interfaces.

Perhaps there’s an audience for one, but it hasn’t appeared yet. I think there’s a simple reason why not. Rails is being developed by its users, and no one working with Rails has the problem that an interface builder would solve. Or more precisely, everyone has other problems that they feel are more pressing.

If you like Interface Builder, then you should certainly keep using it. NeXT and Apple have put an enormous investment into it, RubyCocoa works great with it, and it is undeniably a step ahead of the C++ and Java-based tools that try to compete with it.

But I think that working with Ruby has advantages. The two biggest problems that I have with Interface Builder are that it tends to hide what Cocoa is doing for me and that it overloads my short-term memory. Maybe it’s just my problem, but I’d personally rather see the details and build up my own information-rich displays and abstractions. Ruby makes it easy for me to do that.

I have this crazy thought that the story of Ruby and Interface Builder may be like the one of Snow White and her stepmother queen: someday we’ll look back and say that Interface Builder looked pretty good until Ruby grew up.

Apple Computer has delivered a lot of great developer tools. The tools that Apple provides free of charge would cost a fortune on other platforms, assuming that you could find them. Apple’s documentation and sample code library make it easy to get started with Cocoa and Objective-C, and of course, if it wasn’t for Cocoa and Objective-C, we might instead be stuck swigging MFC.

TextMate has grown to be a fabulous text editor for Ruby programming. Buy it and support independent software development.

The RubyCocoa console might not have been possible without the examples provided by Bob Ippolito’s PyInterpreter and Martin DeMello’s FXIrb.

The menu making DSL was inspired by Rich Kilmer’s spellbinding presentation at the Silicon Valley Ruby Conference in April 2006.

RubyCocoa is the original product of Hisa Fujimoto with early help from Chris Thomas of Apple. More recently Kimura Wataru, Jonathan Paisley, and Laurent Sansonetti have made significant contributions to the RubyCocoa project.

I’m Tim Burks. Thanks for reading!