Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Mix it, Baby!

Just found James Duncan Davidson's article Sometimes Carbon isn't that bad.... I'm an old Carbon nut (actually I started with Classic Toolbox in System 7) who came to Cocoa and loved it. So, it may not be too surprising that I agree with him. However, I think he's only gone part of the way:

Why not extend this to other languages? In the end, programming languages are all just tools. And there's always the right tool for the right job. While most people do not know it, Apple and the GCC folks have managed to make it easy to integrate all sorts of languages into a Mac app these days.

Even in the MacOS 10.0 days it was already possible to mix assembler, Smalltalk and any other GCC-supported programming language into your sources. NeXT one-upped them by choosing Objective C instead of Smalltalk, which, being a C superset, allows integrating any C code you want right into your application. And then we got Objective C++, which allowed the same for C++.

But Apple didn't stop there: They built various bridges between Cocoa and other languages. The first time I looked at the docs for the Cocoa/Java and Cocoa/AppleScript bridge, I was shocked to find out how easy it is to mix-and-match between these languages. If you've used CoreFoundation's toll-free-bridged objects, you've still been suffering more than you should have.

And the open source community picked up the ball. There are now numerous other bridges for up-and-coming languages like Ruby and Python, there's StepTalk that can be linked into any application to surf around and look into your app with powerful Smalltalk syntax (including blocks, which are way cooler than enumerators, and much less typing work).

Now granted, I haven't had the time to use most of these yet (so far I stopped after AppleScript, Java, C and C++), and AFAIK StepTalk has only recently been ported from GNUstep to OS X, but the Mac isn't just some fancy digital hub that promises one day that it can do the same as your TV, just that you can additionally browse the web during commercial breaks (*grins*). Due to the Carbon/Cocoa/Java dichotomy, the Mac has instead become one of the best platforms for integrating heterogeneous systems.

Instead of the old scheme where you picked the language that offered the best features for 90% of your project, you can now decide anew for each part. And Apple keep adding new open-source packages. 10.3 IIRC added Python and the PHP command-line tool.

Of course, mixing and matching opens its own can of worms. If a core part of your app relies on an exotic language, it may be hard to find people who are qualified to work on it. Also, it will limit mobility of your programmers. If the parser is written in Perl, you may not be able to have the C++ programmer who does the GUI apply a quick fix when you're in a tight spot.

But even if you use only two languages, and one of them is one of the popular ones, that may save you the time you need to speed past your competitors with a more mature product.

... well, at least that's the theory... :-)

 
Created: 2005-03-01 @632 Last change: 2005-03-01 @656 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.