If you've ever written cross-platform code, especially between little and big endian machines, or even worse, different 64-bit implementations, then you know that compilers can't even come close to solving everything for you.

Cross platform code needs lots of thought and hard work. THAT is why VM languages are nice.

As for JITs, yes, they're getting much faster and much better at recognizing code to optimize. Then again, so are static compilers. But both of these technologies are slowly merging together. JITs are getting ahead of time compilation, and static compilers are getting profile directed compilations.

You just have to ask yourself, is a 40% boost in performance worth hours, possibly weeks, of rewriting code for a different platform?

You don't need a VM to solve endian issues. This can be handled at the framework or library level. For example, the NSCoder class handles most of this for you in the OSX/iOS world. Conform to the NSCoding protocol and endian issues during serialization are handled for you.

Many apps and libraries are ported, not written from scratch. You may not have an option to "conform to the NSCoding protocol", because you already have existing code, written before Apple Era.

It is actually a problem on Macs: there are entire libraries of applications, that will never run on any new Mac. PPC/Classic is not supported, PPC/OSX may or may not run, depending on the app. Forget 68K/Classic.

(Yeah, I should have bought PC versions of Lucasfilm games, not the Mac ones.)

Unofficial but works: http://www.macwindows.com/OS9_on_Intel_Mac.html

You can't run them on ScummVM?

And you just made the point for why use VMs ;-)

Wouldn't it be nice to have a ScummVM that can run not only games but real applications?

Yes, in this case, that's exactly what I do.

But the point is that I shouldn't rely on group of volunteers to preserve compatibility. For Lucasfilm games it works, for others it doesn't (other "classic game", Diablo II, has PPC/Classic installer and PPC/Carbon update. It is uninstallable on current Macs). It is not just about games either - how many people were satisfied with Photoshop 7 (PPC/Classic), but they had to purchase newer version just to be compatible with their platform? Specifically Apple had quite a lot of ABI breaks in their history.

But back to the article - it claimed, that architecture specific binaries are not a problem. I think, and many people agree, that having architecture independent binary is a good thing and provides real benefits not just to developers (fewer builds and reduced support), but to end-users too - compatibility with wide array of devices. You can develop for Snapdragon/Hummingbird (ARM) device and the same binary will run on Moorestown (IA32) or some random Freescale (PPC) too.

Great ... so you're gonna build a dozen binaries (or more) and upload all of them to the App Store?

That's rich.

Actually, the compiler would output a single duodecimal-fat binary. (Analogous to quad-fat binaries from the NeXT days.)

On a phone that has limited storage space?

And there's another thing ... with Android I'm not sure if it will run correctly on a "Samsung Galaxy S" if I've only tested my app with the Nexus One, but at least I know it will execute.

If you're reuploading an update for Samsung, it will surely not be one about binary-compatibility.

iTunes could perform liposuction (seriously, `man 1 lipo`) on the app bundle when transferring to the device.

But how does the compiler create binaries for CPUs that don't even exist yet?

He is wrong.

While ARM is a good target, there are many variations, with different feature-sets, added instructions and JVM acceleration that make for really different targets (much like x86 and amd64) that he would have to upload and test independently. And I am talking about ARM, which is only the dominant mobile platform (and that wasn't dominant a couple tears ago). One may also consider x86 (lpia, maybe) and their own endless SSE variations.

Universal Binaries have made multi-architecture deployment a solved problem since the NeXT days.

Really? They did ARM7 builds at the time?