As dynamic scripting languages become more widely used, many developers are interested in using them to write “native” Mac OS X software, rather than having to learn Objective-C (which, of course, is a dynamic language in its own right). And in fact it is often possible to do so, using Apple’s BridgeSupport to generate the necessary metadata. Apple explicitly supports bridges for Ruby (RubyCocoa) and Python (PyObjC).
Nevertheless, there is necessarily an impedance mismatch between the runtime models — when passing objects to Cocoa, the bridge must convert the object from the dynamic language’s runtime to an Objective-C object derived from NSObject, and vice versa. This introduces a certain amount of inefficiency, which is not normally a big problem, but it would be desirable to avoid it.
Now, over the last few months, I’ve seen a variety of projects to do this by using the Objective-C 2.0 runtime to implement the object model for the dynamic language. In other words, objects in the dynamic language are subclasses of NSObject and no conversion is necessary.
These range from the venerable F-Script, which is even closer to Smalltalk than Objective-C, to Tim Burks’ original language Nu, which uses a Lisp-like syntax. I believe I’ve seen a reference to a JavaScript implementation as well, but I can’t seem to find it now.
The project that seems to be getting the most buzz in the Mac community right now is MacRuby, a port of Ruby 1.9 done by the developer of RubyCocoa (who is also an Apple employee). There was even a article about it featured on the Apple developer site recently.
Conspicuous by its absence from this list is my preferred dynamic language Python. I would love to see an implementation of Python hosted on the Objective-C runtime. I’ve always felt Python’s language model was a good match for Cocoa (of course, PyObjC not only predates BridgeSupport but even Cocoa itself, going back to the days of NextStep), and I’m personally more familiar with it than Ruby or other dynamic languages. So it seems like a logical step to take.
This project couldn’t be called MacPython, because that name has already been used to denote the Mac port of Python. For now I’m calling it “OCPython”, but I’m certainly open to a cleverer name (especially if there’s one that can riff on IronPython; unfortunately the element most associated with Mac OS X is Carbon, which is entirely wrong for this project).
I’ve been thinking about which version of Python to use as a jumping-off point; originally I was leaning towards 2.5 because it’s the version shipped with Leopard, but now I’m persuaded by Bill Bumgarner’s comment to use 3.0 and take advantage of the revised, less crufty implementation. (This is based on the stated goal of the 3.0 development project; I haven’t actually looked at the source code yet.)
I wish I could say I’m prepared to get the project off the ground myself, but right now I’m between jobs, as they say, and given the current financial situation I’m actively looking for full-time employment and can’t dedicate much time to something that won’t bring in any revenue. (Of course, if anyone out there would like to fund development of OCPython, contact me immediately.)
6 Comments