Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

I know some Python and I'm really impressed by the language's ease of use. From what I've seen of Objective-C it looks a lot less pretty, but it seems to be the lingua franca for Mac OS X development (which means it has better documentation).

I'm thinking about starting Mac development - will using PyObjC+Python make me a second class citizen?

like image 407
Wander Nauta Avatar asked Feb 01 '10 09:02

Wander Nauta


People also ask

Is Objective-C similar to Python?

Objective-C is an object-oriented programming language implemented as a superset of C that borrows heavily in concept and syntax from Smalltalk. It features single inheritance with dynamic dispatch and (in theory) multiple root classes. This is basically the same as Python with single inheritance.

Is Python an Objective-C?

An important difference between Python and Objective-C is that the latter is not a pure object-oriented language. Some values are not objects, but values of plain C types, such as int and double. These basic C types can be used as the types of arguments and the return value of methods.


1 Answers

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

like image 103
Peter Hosey Avatar answered Sep 30 '22 19:09

Peter Hosey