Pyobjc VS Rubycocoa for MAC Development: Which Is More Mature

PyObjc vs RubyCocoa for Mac development: Which is more mature?

I would echo Chris' assesment and will expand a bit on why you should learn Objective-C to learn Cocoa. As Chris says, Objective-C is the foundation and native language of Cocoa and many of its paradigms are inextricably linked with that lineage. In particular, selectors and dynamic message resolution and ability to modify classes at run time are required to implement Cocoa technologies such as Distributed Objects and bindings. Although these features are available in other dynamic languages such as Ruby and Python, there is enough of a mismatch in the language models that you will have to at least understand Objective-C to understand Cocoa. I suggest you take a look at this previous question for further discussion: Do I have to learn Objective-C for professional Mac Development?

Fortunately, Objective-C is very easy to learn. I often tell people it will take them a day to learn Objective-C coming from C/C++/Java or LISP, Scheme, or any of the 'newer' dynamic languages such as Ruby and Python. In addition to expanding your mind a bit, you'll learn to at least read the code that is used in virtually all of the Cocoa documentation and examples.

As for Ruby vs. Python, the bridge capabilities are very similar. In fact, they both use Apple's BridgeSupport (shipped with Leopard) to provide the bridge description. Both are supported by Apple and ship with Leopard. It's a matter of personal taste which language you prefer. If you choose Ruby, I suggest you give MacRuby a look. It's definitely the future of Ruby on OS X, as it reimplements the Ruby runtime on top of the Objective-C run time. This provides some nice performance and conceptual advantages (including integration with the Objective-C garbage collection system, a feature currently lacking in PyObjC which uses the native python gc). MacRuby also includes a custom parser that makes the syntax of bridged objective-c methods a little nicer. The downside of MacRuby is that it's not quite ready for production-level use at the time of this writing (June 2009). Since it sounds like this is a learning project for you, that's probably not an issue.

PyObjC / Ruby bridge. Is it worthwhile ?

I would say MacRuby is the way to go if you want to try one of the bridges. It's being developed by Laurent Sansonetti, who's a Senior Software Engineer at Apple working on Ruby.

It's quite functional now, and integrates nicely with the native frameworks. Worth a look, particularly if you already have Ruby experience.

What are the downsides of using Python instead of Objective-C?

Yes.

For one thing, as you note, all the documentation is written for Objective-C, which is a very different language.

One difference is method name. In Objective-C, when you send a message to (Python would say “call a method of”) an object, the method name (selector) and arguments are mixed:

NSURL *URL = /*…*/;
NSError *error = nil;

QTMovie *movie = [QTMovie movieWithURL:URL
    error:&error];

This isn't possible in Python. Python's keyword arguments don't count as part of the method name, so if you did this:

movie = QTMovie.movieWithURL(URL, error = ???)

you would get an exception, because the QTMovie class has no method named movieWithURL; the message in the Objective-C example uses the selector movieWithURL:error:. movieWithURL: and movieWithURL would be two other selectors.

There's no way they can change this, because Python's keyword arguments aren't ordered. Suppose you have a hypothetical three-argument method:

foo = Foo.foo(fred, bar=bar, baz=baz)

Now, this calls foo:bar:baz:, right?

Not so fast. Foo may also have a method named foo:baz:bar:. Because Python's keyword arguments aren't ordered, you may actually be calling that method. Likewise, if you tried to call foo:baz:bar:, you may actually end up calling foo:bar:baz:. In reality, this case is unlikely, but if it ever happens, you would be unable to reliably call either method.

So, in PyObjC, you would need to call the method like this:

movie = QTMovie.movieWithURL_error_(URL, ???)

You may be wondering about the ???. C doesn't allow multiple return values, so, in Objective-C, the error: argument takes a pointer to a pointer variable, and the method will store an object in that variable (this is called return-by-reference). Python doesn't have pointers, so the way the bridge handles arguments like this is that you pass None, and the method will (appear to) return a tuple. So the correct example is:

movie, error = QTMovie.movieWithURL_error_(URL, None)

You can see how even a simple example deviates from what documentation might show you in Objective-C.

There are other issues, such as the GIL. Cocoa apps are only going to get more concurrent, and you're going to want in on this, especially with tempting classes like NSOperation lying around. And the GIL is a serious liability, especially on multi-core machines. I say this as a Python guy myself (when not writing for Cocoa). As David Beazley demonstrates in that video, it's a cold, hard fact; there's no denying it.

So, if I were going to switch away from Objective-C for my apps, I would take up MacRuby. Unlike with PyObjC and RubyCocoa, messages to Cocoa objects don't cross the language bridge; it's a from-the-ground-up Ruby implementation in Cocoa, with language extensions to better support writing Cocoa code in it.

But that's too far ahead of you. You're just getting started. Start with Objective-C. Better to avoid all impedance mismatches between the language you're using and the one the documentation is written for by keeping them the same language.

Plus, you'll find some bugs (such as messages to deceased objects) harder to diagnose without knowledge of how Objective-C works. You will write these bugs as a new Cocoa programmer, regardless of which language you're writing the code in.

So, learn C, then learn Objective-C. A working knowledge of both shouldn't take more than a few weeks, and at the end of it, you'll be better prepared for everything else.

I won't go into how I learned C; suffice to say that I do not recommend the way I did it. I've heard that this book is good, but I've never owned nor read it. I do have this book, and can confirm that it's good, but it's also not Mac-specific; skip the chapter on how to compile the code, and use Xcode instead.

As for Objective-C: The Hillegass book is the most popular, but I didn't use it. (I have skimmed it, and it looks good.) I read Apple's document on the language, then jumped right in to writing small Cocoa apps. I read some of the guides, with mixed results. There is a Currency Converter tutorial, but it didn't help me at all, and doesn't quite reflect a modern Cocoa app. (Modern apps still use outlets and actions, but also Bindings, and a realistic Currency Converter would be almost entirely a couple of Bindings.)

Which is easier for beginners: RubyCocoa or ObjC/Cocoa

I would not recommend learning to program with RubyCocoa.

I love Ruby and think it's a great language to learn programming, but the RubyCocoa bridge isn't documented well enough that I'd recommend it as a learning environment. You'd be learning general programming concepts, the Cocoa frameworks and the quirks of RubyCocoa all at the same time. That's a lot of stuff to shove into your head.

If you're bound and determined to start with Cocoa, start by learning Objective-C. Otherwise, you could learn Ruby to begin with and then transition to Objective-C once you feel a little more comfortable as a programmer. And once you've done all that, you can use RubyCocoa, but then you'll know enough that it won't make you go crazy.

Do I have to learn Objective-C for professional Mac Development?

Objective-C is a dynamic language, as far as the Objective-C parts go. Here's a little summary article: http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html

The syntax is scary at first, but it grows on you. I suggest biting the bullet and slogging through it.

If you want to work at a "real job" doing Mac programming with other people, you're going to need to know Objective-C (in my opinion, anyway).

PyObjc and Cocoa on Snow Leopard

Allow me to echo what has already been said. I too am a student who just started a Cocoa development project, and at the beginning I thought "Well, I already know Python, I'll just use PyObjC and save myself from having to learn Objective-C, which looks beyond my grasp." I learned quickly that it can't be done. You can develop for OS X without learning Objective-C, but not without learning the Cocoa libraries, which constitute 99% of what you need to learn to write a Cocoa app in Objective-C. Objective-C itself isn't that hard; it's the Cocoa libraries that you need to invest in learning.

PyObjC basically uses Cocoa libraries and Python syntax. I gave up with it quickly and decided that if I was going to have to learn Cocoa, I may as well use Objective-C.

If you're looking to learn, Aaron Hillegass's book is a good place to start. Good luck!

Scripting Bridge vs PyObjC vs py2app

The short version: PyObjC is the way you call Mac OS X APIs, Scripting Bridge is the way you talk to other apps' scripting interfaces. In more detail:

PyObjC is a bridge between the Python language and the Objective C runtime (and the set of Cocoa wrappers built trivially on top of that bridge, and some nice convenience stuff). If you want to call Cocoa methods, you use PyObjC, typically by importing either Cocoa or Foundation.

Scripting Bridge is a bridge between the Python language and the Apple Event-based scripting system. If you want to call another app's scripting interface, you use Scripting Bridge. (In most cases, if you're using Scripting Bridge, you'll also want to import Foundation, because Scripting Bridge deals with things like NSArrays, etc.)

So, PyObjC is not an example of a scripting bridge. An example of a scripting bridge is, well, Scripting Bridge, or Appscript (which is better, but not from Apple, and no longer maintained).

py2app has nothing much to do with either of these; it's a way to wrap up a Python application, together with all of the extension modules it requires, and as much of the Python interpreter as necessary, into a single .app bundle that you can distribute to users so they can just double-click to run it. Of course most such apps will have GUIs, and many of them will use PyObjC to create those GUIs directly in Cocoa (rather than using, e.g., PyQt or wxPython), but beyond that, there's no real connection.

Cocotron with pyobjc?

If the performance is not an issue, then why not to use just python without obj-c? wxPython will provide native look and feel on both Windows, Mac OS and Linux. And it's easy to make distributions for different OSes with py2exe and py2app (and linux users have python anyway :-).

BTW: there is a great example of wxPython open-source application - Editra text editor. Also, the author of this program wrote a nice book on development of cross-platform apps with wxPython. _{I'm currently reading it and I enjoy it's short and laconic style. If you want to buy this book - you can complete a survey on the publisher's site and get 50% discount :-) that's what I did.}

---

Related Topics