What are alternatives to Objective-C for Mac programming?

Question

I've become very comfortable in the world of pointer-free, garbage-collected programming languages. Now I have to write a small Mac component. I've been learning Objective-C, but as I confront the possibility of dangling pointers and the need to manage retain counts, I feel disheartened.

I know that Objective-C now has garbage collection but this only works with Leopard. My component must work with Tiger, too.

I need to access some Cocoa libraries not available to Java, so that rules out my usual weapon of choice.

What are my alternatives? Especially with no explicit pointers and automatic garbage collection.

Answer 1

Look at Python and wxPython (the wxWidgets in Python).

The wxWidgets have a very elegant App-Doc-View application design pattern that's very, very nice. It's not used enough, IMO. I haven't found any wxPython examples of this App-Doc-View example, so you have to use the C examples to reason out how it would work in Python.

I'd post examples, but I haven't got it all working yet, either.

Answer 2

You can try PyObjC to write Cocoa apps in python, or MacRuby if you are interested in Ruby.

Answer 3

Try any of the Cocoa bridges listed in here http://www.cocoadev.com/index.pl?CocoaBridges

You can also try F-Script - a smalltalk dialect that is written specifically for MacOSX/Cocoa.

Answer 4

RubyCocoa is getting steadily more impressive, and I've seen lots of successful implementations using it. That is, of course, if Ruby's your cup of tea...

Answer 5

.NET via Mono mono-project.com

Answer 6

What do you mean by "component?" Do you mean a chunk of code or a library you are going to hand to other people to link into their apps? If so then it is not realistic to use any of the bridged languages at this time. While a lot of the bridges are very nice, they almost always have complications and issues that most app developers will not be willing to deal with to use a single component, especially if it involves bringing in a substantial runtime.

The bridges are most valuable to bridge other language libraries into your Objective C app. While you can write fairly complete apps using them, doing so often requires a better understanding of Objective C than simply writing an Objective C application, since you need to understand and cope with the language, object model, threading, and memory allocation impedance mismatches that occur.

This is also why many people argue that even if you are quite familiar with a language, trying to learn Cocoa using that language through a bridge is generally more difficult that learning it using Objective C.

Finally, much of the recent support for bridged languages was due to "BridgeSupport," a feature was added in Leopard. Even bridges that predate that have been migrating towards, sometimes in such a way that using the bridged language on Tiger and Leopard can have substantial differences. Also, there is currently no bridge support for iPhone, and most bridged languages will not work on it, if that is an issue.

Ultimately, if you are writing a library that is going to be linked into other apps, you need to run on Tiger and Leopard, and you need to access Cocoa only APIs I think you will find using any non-Objective C solution quite difficult.

Answer 7

You shouldn't be intimidated by Cocoa's retain/release reference counting. It's much, much easier in practice than GC fans would have you believe. The Cocoa memory management rules are dead simple, they only affect a tiny amount of your code, and even that code can be generated automagically.

Here's the trick. You encapsulate your MM code in accessor methods, and always use accessors. Xcode has built-in scripts to generate the appropriate accessors, or if you need more flexibility there are 3rd-part apps like Accessorizer.

This isn't an intrusive approach - you only need to worry about retaining an object if you're going to need to keep it for later use, and if you're going to do that you'll need an instance variable in which to keep it anyway. And, if you're using KVO and bindings, you'll need to use accessors to make sure the appropriate observer notifications are fired. Basically, if you're using good OOP and Cocoa practices, there's practically no additional thought or effort involved with memory management.

Most folks who have difficulty with Cocoa's "manual" memory management are doing so as a result of misusing it. The most common mistake is to scatter the relevant code all over the place. That means that a missing retain, extra release, etc will be difficult to find.

Answer 8

You can always use REALbasic (www.realsoftware.com). Real easy and fun to use, not free though. You can not make dylibs (or dll's) using it, but you can use dylibs and dll's in your code. And you can use cocoa libraries as well

Answer 9

Don't forget that you can use java as well, and i don't mean java-cocoa bridge, i mean actual java.

There's also a package from apple that provides you with access to a couple of osx features as well.

Also to comment on Shem's point, if your targeting osx 10.5 and above, you can take advantage of garbage collection.

Answer 10

See NObjective (http://code.google.com/p/objcmapper/) bridge to Cocoa. It provides more features than others with less overheads.

Answer 11

If you want lisp syntax then Nu is a lisp implemented on top of Objective-C http://www.programming.nu/

Answer 12

I'm looking into Mono too. Objective-C is a little too bizarre for me at this point. Too many years doing C/C++, Java, C#, Perl etc. I suppose. All these seem pretty easy to float between. Not so for Objective-C. Love my Mac but afraid it will take too much precious time to master the language.

Answer 13

Also, FreePascal can generate native Carbon Apps (in progress working for Coccoa)