Ten Years of OpenStep

Slashdot reports that today is the 10th anniversary of OpenStep, the NEXT/Sun API that now forms the basis of Apple’s Cocoa and GnuStep . Over the past couple of weeks I’ve poked around at Cocoa, XCode and Objective C, even breaking down and buying Aaron Hillegass’s book Cocoa Programming for Mac OS X . I’m actually quite impressed with Objective C and Apple’s developer tools. While Interface Builder was a bit of a mystery to me initially (“outlets? actions? what the fuck?”), reading the Cocoa tutorials on Apple’s developer site cleared up some of the confusion. But I’m not sold (what follows is my own opinion, and as such should be taken with a large crystaline solid composed of sodium chloride molecules).

Without a doubt, Cocoa is a truly object oriented programming environment that encourages well behaved programs in a much better way than Java ever has. Where Java encourages strong typing and object-orientation (except when it doesn’t; cough, primitives, cough), Objective-C (or more accurately, Objective-C along with Cocoa and Apple’s developer tools) encourages a model-view-controller (MVC) design pattern and works to minimize the amount of effort you as a programmer have to do to accomplish the task at hand. When I figured out just how outlets and actions work, it was the proverbial lightbulb; “you mean that’s it?” And PyObjC works just as advertised, seamlessly fusing this convenience with everyone’s favorite language, Python.

So why am I forcing myself to stay away from Objective C, XCode and Interface Builder? Portability. I’m paid to write software that runs on multiple platforms; at least Windows and Mac OS X. And I run Linux at home. The attractiveness of Python (and Java, I suppose) is its cross-platform nature. Writing a single code base that runs on 3 platforms equally well isn’t always easy, but I think it’s worth the effort in maintenance time saved. As much as I enjoy using Mac OS X, I don’t want to be enslaved to it. In fact, I recently installed Linux on my iBook, just for kicks. I might go back, but because I value portability, I have that option.

OpenStep and GNUStep do not ignore portability. The original Next toolkit was available for multiple platforms, and promoted the idea of fat binaries. Fat binaries were the precursor to today’s Mac OS X .app folders: a set directory structure containing compiled binaries for multiple platforms (and architectures). True write once, run anywhere. Unfortunately, Apple seems to have decided fat binaries needed a diet and only supports the “MacOS” target. This is actually an understandable position from a marketing perspective. Apple is a hardware vendor, and Mac OS X (and Cocoa along with it) are strategic advantages for their hardware. Allowing true fat binaries that ran on Windows, Mac OS X and Linux would undermine that advantage.

Today GNUStep is the best hope for reviving this portable vision. Their XML-based UI project, Renaissance , looks promising, and they have an “experimental” Windows distribution . Unfortunately the Windows binaries don’t include their developer tools such as GORM and Project Center , so it’s impossible to know just how well the UI really works on the Windows platform.

Increasing the number of cross-platform development tools, toolkits and languages is in everyone’s best interest. Eclipse has demonstrated the usefulness of cross-platform Java development tools and native-look widget toolkits. wxPython continues to lead the way on the Python platform. Increased competition not only gives developers more choices, it exposes different ways of thinking about problems and the solutions. And ultimately, the freedom to choose the correct solution platform for the problem is the developer’s “Freedom Zero.”