Prognostications and portents
Jun. 4th, 2008 03:56 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kickahaGeek time. (duh.)
Next week is Apple's World-wide Developer Conference, and the rumors, they are flying. One of the more intriguing ones is outlined at http://daringfireball.net/ : that devs will get a preview of MacOS X 10.6, codenamed Snow Leopard. RHI that this will be a speed and stability update *only* - no new features... but that it will be sporting a brand new minor version bump, which is usually reserved for feature-adding releases. Blogosphere whining has ensued. "Pay for no new features? Unpossible!"
Another rumor is that Apple is finally going to drive a stake through the heart of the Carbon APIs - the legacy-induced Mac OS9 compatible API that was created for old codebases to come forward. (It was introduced as a legacy API, devs were told from the first day that it was only temporary, etc, etc, etc... I think 10 years is enough time to migrate code, don't you? Well, unless you're Adobe... man those guys are pissed.) This one is reasonable. Head over to and try and find mention of Carbon in the WWDC Sessions. Go ahead, I'll wait.
Alright, enough time - there aren't any. The hint, it has become a club. Carbon is dead, long live Cocoa. (That's the other API, the one that the NeXT technologies morphed into.)
Common wisdom is arising that the above list is justified by an urge to step back and clean up the OS X tree - both Mac and iPhone variants, and make sure they're in line and cohesive moving forward.
Finally, RHI that Snow Leopard will ditch support for both PowerPC and 32-bit Intel hardware. The first I have no problem believing, the second one is a stretch IMO.
Some rather spot-on folks are convinced that their sources are correct in the above rumors... but they don't make much sense.
Unless...
I have a theory. There is one way that Apple could:
a) Introduce no new user level features
b) Introduce no new developer APIs
c) Work almost exclusively on speed
d) Support their desire to integrate MacOS X and iPhoneOS X (and other versions?)
e) Have Snow Leopard be worthy of a 10.6 version bump
f) *MAYBE* even have it be worth of a paid upgrade (probably not full, but something)
http://www.llvm.org
LLVM is the Low-Level Virtual Machine - it's a compiler infrastructure that is kind of like bytecodes for the JVM. It allows you to compile whatever-language-you-want to an internal representation, and cache it as 'bytecodes'. (They're not, but we'll call them that for ease of discussion.)
Then, you can generate whatever binary you need out the back end.
Okay, so this is pretty normal so far. Most compilers do something similar with object files, etc... except that LLVM defers translation to the hardware language until the last possible point, which means that you can do all sorts of interesting optimizations *at run time*. The binary is emitted via JIT in many cases, and can be updated on the fly too.
Sound fantastic? Not really. This is how CoreImage and CoreAnimation have worked from Day 1. The binary in the application contains an llvm blob that is converted to whatever GPU you have on hand, when you run the app, and not a second before. No GPU? Software rendering.
Apple has thrown a lot of effort (quietly) into llvm and clang, the C/Obj-C front end. Yup, that's right, it does Obj-C beautifully, but C++ support is still in progress. Kinda shows the priorities, huh?
I wouldn't be surprised at all to hear at WWDC that clang is now finalized, with C++ support, and being released back into the open-source world.
This would be a complete replacement for gcc.
Now you have universal binaries that *REALLY ARE*. Not multiple binaries in one package, but *one binary* that can run on multiple hardware systems, at full native speeds, no recompilation. This is what Java *could* have been, if they hadn't lobotomized the bytecodes. (Most idiotic design decision I think I've ever seen.)
Okay, cool. But it gets better.
Use the multicore and threading techniques in Cocoa to partition the implementation space into logical units. Now you can send those units across the bus, or across the network, to run on other hardware *on demand*.
Kinda makes Java look slow and stupid, doesn't it?
No new APIs. No new features at the user level. Just a change in the compilation system.
Hello, world domination.
Next week is Apple's World-wide Developer Conference, and the rumors, they are flying. One of the more intriguing ones is outlined at http://daringfireball.net/ : that devs will get a preview of MacOS X 10.6, codenamed Snow Leopard. RHI that this will be a speed and stability update *only* - no new features... but that it will be sporting a brand new minor version bump, which is usually reserved for feature-adding releases. Blogosphere whining has ensued. "Pay for no new features? Unpossible!"
Another rumor is that Apple is finally going to drive a stake through the heart of the Carbon APIs - the legacy-induced Mac OS9 compatible API that was created for old codebases to come forward. (It was introduced as a legacy API, devs were told from the first day that it was only temporary, etc, etc, etc... I think 10 years is enough time to migrate code, don't you? Well, unless you're Adobe... man those guys are pissed.) This one is reasonable. Head over to and try and find mention of Carbon in the WWDC Sessions. Go ahead, I'll wait.
Alright, enough time - there aren't any. The hint, it has become a club. Carbon is dead, long live Cocoa. (That's the other API, the one that the NeXT technologies morphed into.)
Common wisdom is arising that the above list is justified by an urge to step back and clean up the OS X tree - both Mac and iPhone variants, and make sure they're in line and cohesive moving forward.
Finally, RHI that Snow Leopard will ditch support for both PowerPC and 32-bit Intel hardware. The first I have no problem believing, the second one is a stretch IMO.
Some rather spot-on folks are convinced that their sources are correct in the above rumors... but they don't make much sense.
Unless...
I have a theory. There is one way that Apple could:
a) Introduce no new user level features
b) Introduce no new developer APIs
c) Work almost exclusively on speed
d) Support their desire to integrate MacOS X and iPhoneOS X (and other versions?)
e) Have Snow Leopard be worthy of a 10.6 version bump
f) *MAYBE* even have it be worth of a paid upgrade (probably not full, but something)
http://www.llvm.org
LLVM is the Low-Level Virtual Machine - it's a compiler infrastructure that is kind of like bytecodes for the JVM. It allows you to compile whatever-language-you-want to an internal representation, and cache it as 'bytecodes'. (They're not, but we'll call them that for ease of discussion.)
Then, you can generate whatever binary you need out the back end.
Okay, so this is pretty normal so far. Most compilers do something similar with object files, etc... except that LLVM defers translation to the hardware language until the last possible point, which means that you can do all sorts of interesting optimizations *at run time*. The binary is emitted via JIT in many cases, and can be updated on the fly too.
Sound fantastic? Not really. This is how CoreImage and CoreAnimation have worked from Day 1. The binary in the application contains an llvm blob that is converted to whatever GPU you have on hand, when you run the app, and not a second before. No GPU? Software rendering.
Apple has thrown a lot of effort (quietly) into llvm and clang, the C/Obj-C front end. Yup, that's right, it does Obj-C beautifully, but C++ support is still in progress. Kinda shows the priorities, huh?
I wouldn't be surprised at all to hear at WWDC that clang is now finalized, with C++ support, and being released back into the open-source world.
This would be a complete replacement for gcc.
Now you have universal binaries that *REALLY ARE*. Not multiple binaries in one package, but *one binary* that can run on multiple hardware systems, at full native speeds, no recompilation. This is what Java *could* have been, if they hadn't lobotomized the bytecodes. (Most idiotic design decision I think I've ever seen.)
Okay, cool. But it gets better.
Use the multicore and threading techniques in Cocoa to partition the implementation space into logical units. Now you can send those units across the bus, or across the network, to run on other hardware *on demand*.
Kinda makes Java look slow and stupid, doesn't it?
No new APIs. No new features at the user level. Just a change in the compilation system.
Hello, world domination.