Objective-C, Ruby and Python for Cocoa

Objective-C, Ruby and Python for Cocoa
theocacao.com

Objective-C:

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

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

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

(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.

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.