This whole article is a rambling mess that contradicts itself so much that it says nothing in the end. He takes 2/3rds of the article to tell you the history of Java, and why, despite the fact that he loves VMs, he hates Java, and it too is a piece of crap.
Also, he says that Dalvik is great, but Dalvik sucks because it is on a mobile device. Open SDKs are great, but not if they interact with a VM. We should have native code without a VM, or a VM without native code. But native code is bad because someone might do bad things with it and no one is minding the shop in Marketplace to prevent it.
So, all I can get from this article is that this guy loves the iPhone, and is looking for any and every reason to hate Android.
I think you are completely missing the point. Either you should be doing everything in the VM, or everything bare metal. Allowing all the apps to execute on either bare metal or the VM at discretion is a resource / security / policy management nightmare. Dalvik however really only functions currently with Java. So effectively you end up with having to provide other languages hooks into Dalvik, or getting rid of Dalvik entirely. Most of these comments really are completely off base. Did anyone actually take the time to read this before posting?
Well, he acknowledges that you can do native code, but then he argues that native code is actually bad because the marketplace isn't screened, so people can easily post malware that relies on native code exploits.
His unspoken assumption is that Apple's manual review process would somehow reject an app that contains a native code exploit -- which is baseless. It's not like they have people reading the source code. As far as I can tell, the reviewers just run the apps to look for content and branding problems, and sometimes they don't even catch those. And an exploit relies on a flaw that the system designers don't know about -- the reviewers wouldn't know what to look for even if they wanted to prevent exploits.
Except there is the NDK (http://developer.android.com/sdk/ndk/index.html) which he points out. It seems like he fails to understand how it works though. It allows parts of the application to be written in C or C++ and hook into the top layer of Java. It isn't "running inside the VM" it's running outside of it and communicating with it. Further, the android platform restrictions are enforced at the kernel level so C and C++ code runs under the same restrictions as those in the VM. It simply allows you to do manual memory management for high performance code.
I agree. This article is just a gigantic headache that tries to sound authoritative but actually offers no sound technical arguments on anything. I mean what a mess. It's so incoherent you almost can't respond to it.
11 comments
[ 3.2 ms ] story [ 32.2 ms ] threadAlso, he says that Dalvik is great, but Dalvik sucks because it is on a mobile device. Open SDKs are great, but not if they interact with a VM. We should have native code without a VM, or a VM without native code. But native code is bad because someone might do bad things with it and no one is minding the shop in Marketplace to prevent it.
So, all I can get from this article is that this guy loves the iPhone, and is looking for any and every reason to hate Android.
His second beef was that, the way they don't manage the marketplace very much, it's very insecure.
The whole thing reads like a rant from two years ago.
His unspoken assumption is that Apple's manual review process would somehow reject an app that contains a native code exploit -- which is baseless. It's not like they have people reading the source code. As far as I can tell, the reviewers just run the apps to look for content and branding problems, and sometimes they don't even catch those. And an exploit relies on a flaw that the system designers don't know about -- the reviewers wouldn't know what to look for even if they wanted to prevent exploits.
I would think that 90 million triangles/sec (3x that of iPhone 4) would be enough to do fast, 3d games.