Objective-C, Ruby and Python for Cocoa

I stayed out of the Cocoa language bridging discussion for a few days. I had some initial reactions, but I wanted to make sure they were legit and listen to what people had to say first. The biggest unnamed factor in all of this, I think, is Objective-C 2.0.

First, just a quick rewind. On the Hivelogic podcast, John Gruber talked to Dan Benjamin about the Ruby and Python bridges being bundled in Leopard. In essence, Gruber suggests that Cocoa programmers would prefer to use Ruby or Python if performance wasn't an issue. Here's the quote:

The reason people love Python and the reason people love Ruby is they love the syntax. [...] Even people who really, really love Objective-C and Cocoa, they love it because of what it lets them do. Most people don't really say "this is beautiful syntax."

That's true, but I think it's a little misleading. I think you'll find that most Cocoa programmers enjoy the Objective-C syntax, mainly because it's very simple and straightforward. In fact, it's much simpler than C++, but you don't hear about this as much because it's not newsworthy.

People talk about Ruby's syntax because it really stands out. Objective-C's standout feature is the fact that it's a dynamic language which is compiled. It can call into C and C++ while maintaining runtime class changes and message redirection.

Many of tedious aspects of Objective-C — memory management and accessor maintenance, for example — go away in Leopard if you want them to. These changes are, of course, designed to reduce code.

Gruber suggests that Ruby is a logical replacement for Objective-C in many cases because you can do so much in so few lines of code and it looks. But there's a subtle point there: Cocoa is not about the fewest possible lines of code, but rather making every line tell.

Some things that allow Ruby programs to be very short involve language cleverness or even basic terseness, some of which can be found in Perl and Python as well. This isn't always a good thing in Cocoa. The overriding goal for Cocoa is clarity and simplicity, and sometimes the most straightforward thing is not the shortest or the most clever. What's clever to you may be confusing to someone else reading your code.

Higher Level Abstractions

Gruber goes on to explain that he's not trying to put down Objective-C (which is clear when you hear it in context), but he thinks programmers will prefer to use Ruby or Python wherever performance is not a significant factor, because you have to write less code. Daniel Jalkut expands on this a bit:

...it's exactly what programmers have always done when they switched to a higher level language. 10 years ago a programmer would be more likely to "switch to assembly" for a much-needed performance boost. Has it come to this? Are we moving to a higher plane?

(Side note: I think this might unintentionally give some the impression that C and Objective-C are similar, which is only true to the extent that milk and milk chocolate are similar).

In a follow-up comment on Daring Fireball, Gruber adds this:

Back in the really old days, before Perl took off for web programming, people used to write CGIs using C. And then when Perl started getting popular, some C programmers said it wouldn’t work because Perl was slower than C. In the meantime, while the C curmudgeons were complaining, those who embraced Perl were building the Web.

In both of these cases, switching to the higher-level language made the code much easier to manage and didn't present any significant functional drawback. In other words, it wasn't just that you were further away from the processor, but that you actually ended up with better code in most cases.

That later case is particularly interesting because Perl was designed for text processing, which is what CGI programming was all about at the time. There was rarely a functional advantage to using a character buffer over a Perl string.

This isn't the same situation Cocoa finds itself in. Ruby isn't just a higher-level version of Objective-C. Both are dynamic languages with a high-level syntax, and each has evolved around their areas of specialty. For web apps, text processing is very important. For desktop apps, calling into existing C and C++ code is invaluable.

Variable typing can be very useful. AppKit and Foundation alone have hundreds of classes, and that doesn't even include everything in Application Services, Core Foundation, Core Image, an so on. With so many data types, it's not clear to me if you really want to optimize for the assumption of most things being strings or numbers.

In any case, typed variables in Objective-C are not a constraint imposed by the compiler. Although typed variables are generally necessary in C so that you can get proper data sizes, Objective-C uses them as hints to the programmer and the compiler. You can discard most of them if you really want to.

Stripped-Down Objective-C

Because Objective-C is a dynamic language, methods are bound at runtime. Classes, too, can be changed on the fly and messages can be redirected at will. This is how things like NSUndoManager, Core Data and Key-Value Observing are possible, and why Java never had a very easy time with any of this.

In addition to all of that, the typing of variables and return types is mostly optional. Here's an example:
- personProperties
{
   id person = self.person;
   person.firstName = @"Douglas";
   person.lastName  = @"Adams";
   person.favoriteColor = self.defaultColor;
   person.birthDate = self.defaultDate;

   return person.properties;
}

This is perfectly valid Objective-C 2.0 code — variables are only typed by choice. Up until Leopard, there was some extra noise in the syntax related to memory management and accessors, but with garbage collection and properties, all of that can vanish if you want it to.

Also, even as far back as Mac OS X 10.0 (and beyond) methods without return types are assumed to be id, as are method arguments without a type. So these two are equivalent:
-personWithTemplate:template;
-(id)personWithTemplate:(id)template;

This gives you room to return an NSNumber, an NSArray, an NSManagedObject, or practically anything else.

So why does no one do this? Because it's not about the fewest number of characters, it's about removing ambiguity. There are places where the id type is used by Cocoa, but it's where you legitimately want a generic type, such as valueForKey or delegates.

Writing Code is the Easy Part

If we take the previous stripped-down example and add some optional typing information, it looks a bit more like this:

- (NSSet *) personProperties
{
   PersonProxy * person = self.person;
   person.firstName = @"Douglas";
   person.lastName  = @"Adams";
   person.favoriteColor = self.defaultColor;
   person.birthDate = self.defaultDate;
  
   return person.properties;
}

This version takes slightly more time to type, but without the type information, I might assume personProperties returns a NSDictionary and person itself is a Person object. In this case, though, it's actually an PersonProxy class and the properties are contained in an NSSet.

I could figure all of this out by trial and error, and it's it's not that I'm worried about things breaking at runtime — it's that variable types help me understand the intent of the code. It's like a comment the compiler can use. Units tests can prevent logic errors, but they can't help me or the compiler read the code. Programmers do more reading of code than writing.
                            
Is it technically possible to build Cocoa projects without type information? Absolutely. That, combined with dynamic messages, foreach loops, properties with dot syntax, and garbage collection gets you within throwing distance of a scripting language, all while maintaining all of speed and compatibility benefits of Objective-C.

Headers files and variable typing are tools to help you navigate complex code bases. You can dispense with most of them in Objective-C if you really want to treat Cocoa as a scripting environment, but why throw away what is clearly useful metadata? You don't need to be a compiler or linker expert to use Objective-C.

Use the Tools You're Given

I'm thrilled that Cocoa is gaining built-in Ruby and Python support, particularly because it lowers the barrier to entry. I think it will mean we'll see a lot more people get involved in Cocoa.

I don't think it's going to mean a mass migration of existing Objective-C development to a scripting language, at least not anytime soon. Even if performance was not an issue, Objective-C simply offers too many advantages, not the least of which is that it's the language that Cocoa is built around. For example, look at this example of creating a timer in Objective-C:
timer = [NSTimer scheduledTimerWithTimeInterval: 1.0/60.0
                                         target: self
                                       selector: tick
                                       userInfo: nil
                                        repeats: YES];

Here's what it looks like in Ruby (from Tim Burks's excellent RubyCocoa site):              
@timer = OSX::NSTimer.scheduledTimerWithTimeInterval_\
target_selector_userInfo_repeats(\
1.0/60.0, self, :tick, nil, true)

(I'm not intentionally misformatting this. I'm not sure if it's convention to break these things up into multiple lines.)

Cocoa is designed for multiple named arguments at the language level, which is something Ruby does not currently support. Rails tackles this with named hashes, but that approach has its own challenges since applying that to Cocoa means you'd be changing the actual method names.

Cocoa and Objective-C are not independent tools that just happened to be dropped in the same bin, they're designed to work together. Separating the two is like installing Mac OS X on a Dell.

I'm also curious how the debugging process goes with gdb. It looks like Ruby objects can talk to gdb, but it seems things could get interesting when Ruby and Objective-C method talk back and forth.

Balance of Available Options

What this all comes down to is two points:

1. Mac application development revolves around Cocoa.
2. Cocoa revolves around Objective-C.

There are other possibilities on both points, some of them quite good, but it all comes back home to this. The Ruby language has some incredible features that Objective-C does not, and the opposite is also true. I recently helped port a PyObjC app with Quartz bindings to Objective-C. Admittedly, I'm not an expert in Cocoa bridging, but I do have some recent experience in this area, so it's not all just guessing.

If you look at the site archives, you can see I'm a big fan of Ruby and Rails in particular, but the the question isn't if the language itself has value, it's which language is the best fit for Cocoa.

As far as I can see, the scales are tipped in the direction of Objective-C for most moderate-size desktop Mac apps. It will not always be this way, but that's how it is today. The key is that Objective-C is tuned exactly for what a Cocoa app needs: compiled code, dynamic dispatch, simple language constucts, and easy call-in to C and C++.

This last point is important. In a Rails app, you can do practically everything you need to do from Ruby. For a desktop Mac app, Objective-C is often just the core. Large parts of the Mac OS X API — not to mention huge amounts of multi-platform code — is implemented in C. Being able to call that right inline is invaluable. As invaluable as having built-in regex support for web apps.

Despite all the progress that has been made, I think web and desktop development are still not all that similar — at least if you're building the sort of apps Mac users are used to. When you have multiple threads, persistent state, interprocess communication, graphic contexts, notifications, and so on, things look a bit different. The other big factor that a web app mostly sits between the server and the browser. A desktop app involves more direct interaction.

An Ongoing Evolution

Although a typeless scripting language is a proven good fit for the web, it doesn't necessarily carry over directly to a desktop environment like Cocoa and all of the related frameworks (many of which are not available from the bridge). It might carry over, but it has to re-prove itself. Maybe Ruby will change to better fit Cocoa, or vice-versa.

It is certainly possible to do a lot of the core interactions in Ruby or Python, but Apple specifically provides Objective-C because it helps all of this stuff fit together nicely. That's why it went the trouble of creating a new version of the language with a brand new runtime.

In fact, if there was no such thing as Objective-C 2.0, I think this would be a much different discussion. The advantages of garbage collection, properties and foreach loops are so significant that the lack of them might actually trump the speed and integration — but the new syntax and runtime tip the balance back in the favor of Objective-C, at least for the next several years.

Of course, I could be wrong about all of this. Maybe Ruby Cocoa or PyObjC will take off. For further reading, though, check out these Cocoa Dev Central tutorials:

Objective-C Style I
Objective-C Style II

Let me know what you think. Finally, it's worth noting that there are a few things about the Objective-C 2.0 runtime that aren't public knowledge yet, but do have an impact on this overall discussion.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.