Theocacao: MailDemo as a RubyCocoa Bindings App

MailDemo as a RubyCocoa Bindings App

Tim Burks has repurposed my little MailDemo sample app as a RubyCocoa project. This is the app that is used in the Cocoa Dev Central Bindings Tutorial. The interesting thing about this, of course, is that it's Ruby using Cocoa Bindings.

Although I think this is an interesting example project, I don't entirely agree with the commentary:

The problem is that Apple tells everyone to use Interface Builder to configure their controller objects, and the only way to do that is by clicking from screen to screen in Interface Builder. After you've done it a while, you might eventually get used to it, but you can seriously lose the forest in the trees[...]

The alternative would have been to make all the connections by writing code in Objective-C, and that would have required many pages of error-prone code. But Ruby is a lot more expressive than Objective-C. What if we made our bindings in Ruby?

I think there are tradeoffs in both directions. If you setup everything in code, you have a lot more code to write, read and maintain. Setting up bindings in Interface Builder generally seems a lot cleaner to me, and you're letting IB do what it specializes in, but I realize some people like to see everything in code. You can also always just look in the nib file to see what's going on.

I can't tell if the term "error-prone" above is describing the inherently tricky nature of programming computers or if the author actually feels Objective-C is more error prone than Ruby, which I'd disagree with.

The code for the project also reminds me that although I really like Ruby when working Rails or for individual scripts, Objective-C seems to be a much better syntax fit for Cocoa. For what it's worth, I don't think I'd want to write Rails apps in Objective-C. Using the language that the framework is designed for makes a big difference.

The good news is those that do want to use Ruby for Cocoa will have the option right out of the box in Leopard. How about Rails applications that use Quartz and Core Image?

MailDemo as a RubyCocoa Bindings App
Posted Jan 5, 2007 — 8 comments below

Andrew Knott — Jan 05, 07 3052

So, so sweet.

Laurent Sansonetti — Jan 05, 07 3053

Just a few points :)
First, this is Tim Burks and not Blake Burks. Second, this MailDemo sample is written for the ObjCRuby bridge, Tim's new project. It is not for RubyCocoa, though you should be able to do the same thing for it (we might also want to port it as sample code). And third, in the latest RubyCocoa unstable releases (see there) there is support for a bunch of new frameworks, including OpenGL and QuartzCore (so, CoreImage). A new unstable release is planned for the next week.

Scott Stevenson — Jan 05, 07 3054

I already apologized to Tim for the name confusion. I need to do more research on the Ruby bridges because Tim's other site is, in fact, called RubyCocoa, as I'm sure you know. Good to know about the framework support.

Tim Burks — Jan 05, 07 3056

Hi Scott & Laurent, I've created some confusion by publicly announcing my new bridge (RubyObjC). The officially-supported Apple bridge is called RubyCocoa, and that's what I documented at rubycocoa.com. I wrote RubyObjC so that I could do some things differently without bumping into Laurent. As far as my error-prone comment goes, we agree that in general, more code is more error prone than less code, and I find that with Ruby I can express things much more concisely than I can in Objective-C. But to say that no code is better than less code obscures the fact that my bindings have to be specified somewhere, and I'd rather check them by skimming over a few lines or pages of Ruby than by clicking through all the bindings forms in Interface Builder... it's too easy to forget something while clicking around. I suspect that others who use bindings have had this problem too and have probably responded by writing tools to dump and verify the bindings in their nib files.

Scott Stevenson — Jan 05, 07 3057

bindings forms in Interface Builder... it's too easy to forget something while clicking around

It's actually much easier than that. The Instances tab in the document window shows not just static IBOutlet connections, but also bindings. I didn't know about this either until somebody mentioned it recently at CocoaHeads.

I think that's at least as easy to read as code.

Daniel Lyons — Jan 06, 07 3064

I haven't done a lot of programming in either Cocoa or Rails but I will say that, having done several tutorials for Cocoa Bindings, it seemed to me that mistakes made in binding were extremely hard to find. I do remember thinking it would have been simpler to have them specified in code, which can be seen, rather than bindings, which I had to basically redo in order to fix. Whatever is tedious in a tutorial is bound to be seriously frustrating in a real application.

Now, having used both, I would say that of course Cocoa is better to use in Objective-C. Every language has its own flavor and Objective-C is somewhat stranger than most. But the fact is Ruby is a higher-level language. I find nothing doubtable in Tim's assertion that Ruby is more concise. Look at ActiveRecord, where one line of code like acts_as_tree can have such far reaching ramifications as defining a half-dozen methods based on optional parameters. You can tell it's higher level because declarative seeming constructs like that exist but are still actually implemented in library code. Lisp is even better at this kind of thing with its macro facility.

I say, let's see what he comes up with. It won't be as good as some idealized Ruby GUI framework that doesn't exist, but it will probably be good.

Scott Stevenson — Jan 06, 07 3069

Look at ActiveRecord, where one line of code like acts_as_tree can have such far reaching ramifications as defining a half-dozen methods
There's no doubt Ruby is a fantastic language. I really like it. But there's nothing that would stop Objective-C from doing something very similar to acts_as_tree. Objective-C, like Ruby, has runtime features that allow for adding methods on-the-fly and responding to messages that aren't implemented. The only difference is you'd have to do acts_as_tree() or something like that for syntax reasons.

The reason I personally prefer Objective-C for Cocoa is I find its syntax much easier to read and write for Cocoa code, which is probably because Cocoa was designed around it. I also think there's a sweet spot desktop development where a language is is both compiled and dynamic.

Those are just my preferences. If other people feel Ruby fits them better for Cocoa, then so be it.

Rob Rix — Jan 15, 07 3242

Scott,

The Instances tab in the document window shows not just static IBOutlet connections, but also bindings.

Thank you for making this wider known. The interface is a wee bit odd to figure out at first, but it is a very useful thing indeed.

Comments Feed