Objective-C, Ruby and Python for Cocoa

by swombat • 18 years ago

29 25 18 years ago

halo• 18 years ago

I think this may be validation of Microsoft's approach with the .NET platform since one its core conclusions seems to be that Cocoa is too closely coupled to Objective-C to make alternative dynamic languages attractive as they don't "fit together nicely". The other line of discussion it goes down is whether or not Objective-C is the best option, but that's always going to end up being a matter of taste.

jmah• 18 years ago

I don't think he's passing judgment, saying that Cocoa is too closely coupled, I think he's just comparing why it works better with Objective-C than with Ruby. Amongst other interesting projects are Nu, a Lisp designed for Cocoa and Objective-C; and MacRuby, a fork of Ruby that uses Objective-C's runtime and garbage collector, and language tweaks for named arguments.

http://programming.nu/

http://www.macruby.org/

tptacek7• 18 years ago

He doesn't really present any evidence as to why it works better with ObjC than Ruby, though.

Hoff• 18 years ago

Cocoa meets Javascript: http://cappuccino.org/

tlrobinson• 18 years ago

Cappuccino meets Ruby: http://github.com/tlrobinson/cappruby

It's very incomplete... a proof of concept.

The bare bones sample app works, here's the Ruby version:

http://github.com/tlrobinson/cappruby/tree/master/TestApp/Ap...

and the original version:

http://github.com/tlrobinson/cappruby/tree/master/TestApp/Ap...

protomyth2• 18 years ago

My biggest problem with Ruby for Cocoa work is that I enjoy the Smalltalk message passing syntax (keyword) more than the C++ syntax (object.name). The hacks to make it work right in Ruby do not look quite right.

Objective-C fills the place C++ or C# fill in the .NET platform world. It would be interesting to see a language built for Cocoa that fills the VB role.

tptacek7• 18 years ago

I had the same reaction, but ObjC's method names are so bad that I just wound up writing my own Ruby wrappers anyhow, so most of my code is written in Ruby idiom.

ObjC does not fill the role C# fills in .NET. ObjC is still C code. C# doesn't have pointers. It doesn't segfault. Every object has reflection. There aren't aliasing problems. ObjC fills the place C++ fills in Win32; we still need a C# replacement.

protomyth2• 18 years ago

Well, I was going with the C++/C# is the "do more" option and VB is quicker / easier.

Just a note: ObjC has reflection.

devrieda• 18 years ago

This is a little bit of an older article and Apple has since been working on MacRuby (http://www.macruby.org/trac/wiki/MacRuby) which is poised to replace RubyCocoa. MacRuby adds a special syntax to Ruby to better deal with the keyed arguments. From the docs:

Objective-C:

  NSWindow *window = [[NSWindow alloc] 
      initWithContentRect:frame 
      styleMask:NSBorderlessWindowMask 
      backing:NSBackingStoreBuffered 
      defer:false];

RubyCocoa:

  window = NSWindow.alloc.initWithContentRect_styleMask_backing_defer(
      frame,
      NSBorderlessWindowMask,
      NSBackingStoreBuffered,
      false)

MacRuby:

  window = NSWindow.alloc.initWithContentRect frame, 
      styleMask:NSBorderlessWindowMask,
      backing:NSBackingStoreBuffered,
      defer:false

look_lookatme• 18 years ago

This is not a special syntax. It's just ruby 1.9 specific hash literal syntax.

jimbokun• 18 years ago

But it looks like the important thing is that they have found a way to automatically map this syntax to Objective C method names.

EDIT: Or, as the MacRuby docs put it:

"MacRuby has a modified version of the parser which detects calls or method definitions using one regular argument, and other arguments using the key/value pair syntax. It will reconstruct the Objective-C full selector if needed. The method name that will be used in the Ruby VM is the same as the Objective-C selector."

http://www.macruby.org/trac/wiki/HowDoesMacRubyWork

tptacek7• 18 years ago

I'm doing a bunch of work in Ruby/Cocoa right now and I am having no problems. Highly recommended. Thoughts:

(1)

ObjC syntax is clearly clunkier than Ruby syntax; you can't honestly compare the two languages without noting that Ruby has arrays and tables as first-class citizens, and ObjC has them only as libraries. You could stop right there; your ObjC code is littered with "dict.objectForKey" and "dict.setObjectForKey" calls, and your Ruby code isn't.

The keyword argument bridge syntax turned me off too, but the reality is that 80% of the pain is due to Cocoa's incredibly verbose method names; for instance:

OSX::NSColor.colorWithCalibratedHue:saturation:brightness:alpha

(2)

You can turn garbage collection on in 10.5 ObjC projects, but it isn't recommended; you lose 10.4 compatibility, and allegedly take a performance hit. The Ruby/Cocoa bridge handles retain/release counts automatically.

(3)

Ruby can call into C/C++ code too; there are multiple FFIs (I've done a lot of work with Ruby/DL) and if you're going to suck it up and write C code wrappers anyways, like you would be in ObjC, you can just write a Ruby extension.

(4)

This argument about "OSX revolves around Cocoa and Cocoa revolves around ObjC" is just emotional. What's the thing you can do in ObjC that you can't do in a Ruby/Cocoa project? Ruby/Cocoa can access arbitrary ObjC objects, open them up and redefine methods, or subclass them. In the unlikely event that I find something that doesn't work in Ruby, then I'll go write the 20 lines of ObjC required to make it work, and call into it from Ruby.

It's 2009. We shouldn't be writing application code directly in C anymore.

timburks4• 18 years ago

To be fair, it depends on the application. You might not have to write them, but there are still plenty of applications where memory and speed are issues, and C gives you some really good tools to deal with them, but you're right -- C is not a high level language and shouldn't be used as one. I would go a step further and say that Objective-C also is not a high level language. Most people here would agree, but lots of Cocoa developers see it as the top of their language stack.

When you get serious with it, the Ruby/Objective-C combination has a lot of problems, mainly because the two languages and cultures simply weren't designed to go together. I have some notes on that here http://programming.nu/rubycocoa-and-rubyobjc and if you have the patience, a talk online that I presented at Jonathan Rentzsch's C4[1] conference: http://www.viddler.com/explore/rentzsch/videos/13 MacRuby is a step in the right direction, but in my opinion it's better to use a glue language that's specifically designed for the task (and if you don't like mine, write your own :-) ).

boucher3• 18 years ago

I'd like to know what argument you would make to claim Objective-C isn't a "high level language". Despite the fuzziness of the term, I think Objective-C would meet most any bar that didn't specifically require the language to be interpreted. The only thing I can imagine being an issue is lack of support for closures, but a) it's coming to the language, and b) it's not radically more expressive than what objective-c already has to offer.

tptacek7• 18 years ago

Obviously, you know this stuff better than I do (I've been following you for awhile), but for what it's worth, here are my initial reactions to your post:

(1) Ruby and ObjC have inconsistent syntax, which among other things is the reason we have that crappy snake-case encoding. This is true, but like I said, Cocoa's nomenclature is already so bad that wrapping everything in Ruby idiom was a win for me

(2) Ruby/Cocoa has to bridge Ruby types (Hash) to ObjC types (NSMutableDictionary). It's true, but this is only really painful if you're using the bridge "bidirectionally"; the real win is to stay in Ruby, and use Cocoa like a library, not a second programming environment.

(3) Ruby and ObjC have overlapping libraries, like ActiveRecord and Core Data (or a million smaller examples). With the exception of Core Data --- and in retrospect I wish I'd stuck with ActiveRecord --- I just stick with the Ruby side and use Cocoa only for appkit. Just like above.

(4) Ruby and ObjC are storing redundant objects. The bridge makes this transparent. If I cared about performance, I wouldn't be in Ruby at all.

(5) Ruby and ObjC have totally different memory management schemes. Part of the point of writing Ruby is not to have ObjC's memory management headache, which the bridge takes care of, but I admit that I could find out 6 months from now that that was a bad assumption.

(6) You can't call Ruby from multiple ObjC threads, or really using ObjC threading at all. That would be a problem if I was writing substantial amounts of ObjC code, but I'm not. (I'm also an async bigot, so I avoid threads anyways).

(7) If a Ruby name clashes with an ObjC name, you have to preface the ObjC name with oc_ to call it from Ruby. This does not bother me at all; isn't it exactly what you'd expect when merging two independent environments?

I'm sure this stuff kills you if you have a complicated ObjC/Cocoa application and you want to extend it with Ruby, or if you want to do a Tcl-style integration with Ruby glue code and ObjC engine code. Also, I am totally biased, because in my consulting life I've spent years in Ruby/DL and Win32 doing my own manual bridging and runtime code generation; Ruby/Cocoa is a dream for me. =)

Nu is really cool. But none of my code is written in Nu.

code_devil• 18 years ago

Interesting read.

Objective-C, Ruby and Python for Cocoa

Related Stories