Just after the Mac development love fest that was C4[1], my interest in writing a Cocoa application was piqued. Not being an Objective-C developer (nor having any real incentive to become one), I looked around at the alternatives and saw two different options for Cocoa development with Ruby: RubyCocoa and RubyObjC. After picking the brain of Tim Burks, documenter of RubyCocoa and author of RubyObjC, I was more confused than ever about how to proceed.
Tim has since released a language called Nu, designed exclusively to build on and bridge with Objective-C. As part of his rationale for the new language Tim outlined the problems inherent in bridging Ruby and Objective-C. Phrases like "overlapping", "inconsistent", and "incompatible" litter the document. 'Nuff said.
Nu looks neat. I built it up from source, ran the demos, and poked at the shell. It's got a good vibe to it. But the problem for me arises in the FAQ, in response to the hypothetical, "Can I use Nu without knowing Objective-C?":
"No, at least not if you intend to use it to write Cocoa applications. In my experience, it is a mistake to think that you can use Cocoa from any higher-level language if you don’t understand what’s happening at the Objective-C level."So in order to really use Nu I need to learn Objective-C, Lisp, and Nu itself. All things I'd like to know... except, uh, Objective-C, which I was looking for an alternative to in the first place.
I understand the challenges in using a language bridge without understanding the languages on each side of that bridge. I suppose that redefines what I'm looking for: not a bridge that lets me interact with a toolkit like Cocoa, but a toolkit that supports multiple languages without having to build them from the ground up.
2 comments:
If you know C and any object-oriented programming language, learning Objective-C should take about an afternoon (if not less).
I think most of the bridges are indeed best suited for people who know the Obj-C runtime but want to write (prototypes of) parts of their apps in higher level languages, which can speed up initial development greatly.
The only not-exactly-bridge I know of for any language and ruby is JRuby... I've written code that makes use of java objects just by looking up the javadoc for the API and using it (for the most part) like I normally would any ruby object. The only /major/ funky things you need to worry about are things like to_java, Java::Byte[2048] (to create a 2048 element java byte array), and cases where the java objects themselves have behavior that depends heavily on javaisms. JRuby is beautifully done.
Speaking of java... whatever happened to the java objc bridge?
Post a Comment