Apple's Take on Application Programming Environments?
This is a followup to yesterday’s post on Application Programming Environments. As I thought more about what I wrote, it brought to the forefront some stuff I’ve been wondering about in this area. Specifically, does Apple have a comprehensive strategy/philosophy/outlook on the issue of native code vs. JIT code, or on Objective-C vs. dynamic languages? If so, could someone please explain it to me (and no, I’m not being facetious - I really want to know).
But First, A Mini-rant on Objective C
I don’t like Objective C. Never have. There. I said it. Flame away!
Why don’t I like it? First, let me say what I do like: I think the runtime is amazing in the way it combines dynamic behavior with native speed. I think Cocoa is fantastic. Toll-free bridging is brilliant. But all this discussion of bridging between native languages like C and Objective C and dynamic languages like Ruby and Python has really crystalized for me what I dislike about Objective C: the constant need to do a cognitive shift back and forth between dynamic Smalltalk goodness and static C minutiae. Here’s an example of what I’m talking about, courtesy of Wil Shipley:
- (id)_realItemForOpaqueItem:(id)findOpaqueItem outlineRowIndex:(int *)outlineRowIndex
items:(NSArray *)items;
{
unsigned int itemIndex;
for (itemIndex = 0;
itemIndex < [items count] && *outlineRowIndex < [self numberOfRows];
itemIndex++, (*outlineRowIndex)++) {
id realItem = [items objectAtIndex:itemIndex];
id opaqueItem = [self itemAtRow:*outlineRowIndex];
if (opaqueItem == findOpaqueItem)
return realItem;
if ([self isItemExpanded:opaqueItem]) {
realItem = [self _realItemForOpaqueItem:findOpaqueItem outlineRowIndex:outlineRowIndex
items:[realItem valueForKeyPath:[[self _treeController] childrenKeyPath]]];
if (realItem)
return realItem;
}
}
}
This mix of id and C-style pointer dereferencing just sets my teeth on edge, and after years of using “scripting” languages I’m not super-fond of all those square brackets either. The equivalent code in Ruby would be both more readable and more succinct. I am, of course, aware that this is a subjective aesthetic judgement. If you don’t mind this style of programming, I’m happy for you. But for me it was enough to keep me out of the Cocoa/Mac OS X programming universe - kinda ironic since I once worked in MacDTS and knew more about Mac internals than most folks.
Apple’s Investments in JITs and Dynamic Languages
So despite my inability to overcome my aversion to Objective C, I still try to keep up with all things Mac OS X. It is clear that Apple has a strong commitment to Objective C. They’re making lots of improvements in Objective C 2.0. But they’re also making some interesting technology investments around JITs, dynamic languages, and so forth:
Core Image has a nifty JIT compiler that takes a GLSL code and dynamically compiles it for the target GPU or CPU. Cool.
OpenGL in Leopard uses LLVM to dynamically recompile graphics code on the fly for systems that don’t do hardware vertex shading. This code replaces a previously existing JIT compiler (who knew!).
Apple is doing LLVM work targeting the ARM processor. Is this for the iPhone or something else? Beats me. But using LLVM would allow Apple to build a higher level Java-style VM on top of it but targeting Objective C, or it would let Apple dynamically recompile programs for new processors (kinda like Rosetta on steroids) and architectures: no more fat binaries. Or it could be something else entirely.
Apple is shipping Java with OS X but doesn’t really put a lot of investment into it. They killed the Cocoa-Java bridge. Can’t say I miss it.
They ship Python, Ruby, and Perl with Mac OS X. New bridge technology makes these quite usable with Cocoa, which is cool, but it isn’t clear whether or not these bridge technologies will be included with Leopard or not.
On the other hand, you have the current situation with fat binaries: PowerPC, x86, x64, and maybe even ARM binaries. This is obviously not a scalable solution when you start talking about optimizing for many different configurations of CPU cores, GPUs, etc.
Microsoft’s Strategy
By comparison, Microsoft’s strategy is obscenely simple: .NET everywhere, and dynamic languages are welcome to come along for the ride. IronPython, JRuby, etc. are all supported on .NET. LINQ adds more dynamic behavior to C# and VB.Net. .Net Compact is part of the Windows Mobile story. WPFE will someday have a miniCLR that runs on Macs and maybe elsewhere. Microsoft has buried the hatchet with Novell (unfortunately they seem to have buried the hatchet in the back of the Linux community, but that’s another topic), so the Mono team no longer needs to worry about patent litigation from Microsoft. Heck, they even want Apple to support Cocoa#.
A Plea to the Lazyweb
What I want to know is this: exactly where does Apple see the future of JIT compilers and dynamic languages? Will Apple maintain a slavish devotion to natively compiled Objective C, or do they plan to start moving more and more to dynamic language development as so many others are doing? I’d love to hear what someone from Apple has to say, of course, but welcome contributions from other industry watchers.
One Last Tangent
As an update to my earlier piece, see this interview with Mark Hamburg about the use of Lua in Lightroom:
So what we do with Lua is essentially all of the application logic from running the UI to managing what we actually do in the database. Pretty much every piece of code in the app that could be described as making decisions or implementing features is in Lua until you get down to the raw processing, which is in C++. The database engine is in C; the interface to the OS is in C++ and Objective C as appropriate to platform. But most of the actually interesting material in the app beyond the core database code (which is SQLite) and the raw processing code (which is essentially Adobe Camera Raw) is all in Lua.
[Update 02-17-2007] Corrected some editing errors and typos.]