Slashdot Mirror

DBM has really hit a new low with this "article". It is almost painful to read through with the gaping holes in logic and diction that would make a SMS junkie teenager blush.

According to DBM's logic Apple might have a real nice developer platform on their hands if they'd only port the base API to other platforms. I find this assertion to be pretty ridiculous. OpenStep already lost this battle a decade ago. The problem NeXT ran into with OpenStep was developers were already entrenched with native and proprietary APIs on their platforms of choice. Few developers were willing to drop all of their current code in order to develop OpenStep applications.

There's also the small problem of Apple's OpenStep derived frameworks (AppKit & Foundation Kit) being a tiny (though important) fraction of the frameworks available in OSX. If only Cocoa were ported to other platforms developers would have to write their own frameworks for advanced functionality. Instead of being able to leverage Apple's DiscRecording framework a developer would have to write, maintain, and package their own in order for their app to be as cross platform as Cocoa. Then the argument would be Apple ought to port their more advanced frameworks in order to draw in more developers.

If Cocoa were to be ported to Windows and Linux tomorrow it wouldn't magically bring oodles of developer talent to the Mac. Think of how many KDE and GNOME apps run on Linux, FreeBSD, Darwin/PPC, and Windows with no platform specific patches despite their common API usage. Only the simplest of Cocoa apps would run with only a recompile (or fat compile) on multiple platforms.

DBM doesn't pay nearly enough attention to Java in his little rant as he should. With Java Apple's already got a nice cross platform development environment to work with. Apple ships two J2EE environments, WebObjects and JBoss, as well as J2SE on their client systems. MacOS X is also bundled with a Java/Obj-C bridge which DBM almost totally ignores. The Java bridge gives OSX a serious advantage as a development and deployment platform for Java applications. With the Java bridge a developer can write a single cross platform application model and then stick a native Objective-C/Cocoa based GUI on top of it. Java's huge cross platform development base with a native Aqua GUI.

There's a few languages such as Python, Perl, and Ruby that can be bridged to Objective-C and can access Cocoa. That is not to mention C++ code can easily access Objective-C classes and thus Cocoa just as well as anything else. I don't really see Objective-C to be much of a hurdle in the development of Mac applications.

What it really comes down to is developers who don't want to abandon the APIs they are used to. All porting Cocoa would do is let Linux and Windows users run Mac applications. If everyone could run Mac applications on non-Mac computers the Mac would become a commodity item and Apple would be little more than an iPod manufacturer that happened to write some software. If Macs ran Windows there'd be no difference between a Mac and an HP. If PCs ran MacOS they'd be no different from Macs. In either case Apple would no longer have a whole product to sell. Without a whole product to sell Apple would either just be yet another software company or yet another hardware company. There's hundreds of each of those. Apple makes money by selling a whole computer product.

require 'osx/cocoa'
snd_files =`ls /System/Library/Sounds/*.aiff`.split
snd_files.ea ch do |path|
snd = OSX::NSSound.alloc.
initWithContentsOfFile_byReference (path, true)
snd.play
sleep 0.5
end

Actually, that was intentional: the aliens were named after the anime. There are other anime references in ST:TNG, such as to Dirty Pair.

Now if I can replace
FileMaker <- Applescript -> Quark
with
MySQL <- Python/Perl/etc -> Quark
that would seriously rock. Are you saying I can do that? Can you post a link to some info on getting started?

The stuff in the middle of your diagrams can be any OSA scripting language - it just so happens that AppleScript is the only one with any momentum behind it. Frontier used to be possible. When I get a MacArthur grant, I'll write the perl pieces.

In the meantime, if I had to bet, I'd say Ruby is the most likely sucessor to AppleScript. Maybe OSX 10.5 will support it directly.

You can use Java with the Cocoa frameworks too.

And, more importantly, Ruby! :-)

I haven't attempted to make frameworks and obj-c bridges and such for Project Builder, but it certainly seems easy from the output I've seen in only the past year. Hell, you can even use Perl to build OS X apps with Project Builder.

What other scripting frameworks for Mac OS X are out there? Well there is a very nice one here.

One of the issues that hasn't really been solved on most platforms is the want to have a double-clickable app written in one of these high-level languages. In the case of RubyCocoa and CamelBridge, that problem is solved, thanks to OS X's awesome bundling system.

Take ShuX, the POD viewer for OS X mentioned above, for example. It's written in perl, and aside the perl system that comes with OS X, all it requires is the CamelBridge.framework. When the user decompresses the ShuX tarball, they're presented with a .app- a double-clickable, first-class Mac OS X application. To the user, it appears native in every way. They could easily copy it to other drives and folders with no problems.

They could stuff-it up and send it to a friend- and provided they that had the CamelBridge framework, the recipient could run the app with no fuss. No screwing around with extra dependencies, installing libs, making sure the .pl file is associated with the interpreter. If there are additional libraries that app requires, but aren't generally applicable, they can just be thrown in the Resources subfolder, along with the main.pl script. This isn't quite as big of a deal in perl, because of CPAN, but it could be a huge boon for those using other scripting languages.

AFAIK, this problem hasn't been solved anywhere near this elegantly on other platforms. Keep the user experience very consistent and pleasing, but gives the developer all the option she wants! :)