I disagree with many of your points here. First of all let me address the idea that compatibility is somehow less important than speed. This I vehemently disagree with. I think it's far more important for upgrades and alternate hardware configurations than for high speed NOW.
You see, if we follow Moore's Law and Gene's Law we see that processors double in speed and half in power consumption every 18 months. Now some may argue it's slowing down, but on mobile processors I actually see it speeding up as they implement older desktop processor improvements into the mobile cores. Now, the big thing about this is that these improvements, when dealing with mobile hardware, usually require a COMPLETELY new processor. This means that someone on the "Cutting edge" will have to replace their processor every 18 months to get double the speed. Even worse, this means the "operation window" on compiled apps is 18 months as well! This is unacceptable to many companies and especially difficult when you consider that in addition to recompiling everything for every device, you'll likely have to use new APIs for everything. This is INSANE! It's one of the biggest problems with Windows Mobile devices. I had a Jornada running Windows Mobile and I pretty much just gave up because applications were out there, but it was incredibly difficult to find one that ran on the processor I was using and didn't require newer libraries. I think that Google's approach with Android is incredibly forward thinking and likely the only reason that in the end Android will win out against others. Now, you mentioned flash as fast. Guess what? Flash is an interpreted language JUST LIKE JAVA! You mentioned it runs quickly but in my experience there is nothing slower than Flash. Now, I agree Java is slow. One thing I don't agree with, however, is Dalvik being slow. Dalvik, the Virtual Machine and Bytecode that Android uses is *HIGHLY* optimized for mobile RISC processors and I believe it's well worth the speed loss. >From what I've seen (Android running on Nokia N810) I've noticed that Dalvik based applications actually run significantly faster than Maemo applications. Now, I'm sure this is primarily limited to the simpler GUI design with less overhead and maybe computational intensive apps will run faster on Maemo, but isn't that what cloud computing is all about? Now, the only thing you can't really "cloud compute" is games. It's true that games are intensive apps requiring tons of resources and "bare metal" tends to work best on that. I don't believe this is the supreme end-all though. Games are definitely possible on mobile environments even without "bare metal" access. iPhone has bare metal sure, but you know what? It, as hardware, wasn't designed for games. It's processor/GPU combo were selected for playing music and youtube videos, not for games. As such it's severely limited when games are running on it. It's true that due to that "bare metal" perspective it's still quite decent. However, a newer ARM CPU with any of the newer mobile GPUs will burn any of that speed away EVEN WHEN THE CODE IS INTERPRETED! Let me say that again, interpreted Dalvik games will likely run better than native iPhone games! Now, many may disagree with this, but my argument on future-proofing stands. iPhone will never be able to change CPUs or even GPU architectures without a total rebuild of all applications. Android, however, will run on ANYTHING (even X86) and so is quite literally and thoroughly future-proof. On Oct 3, 9:36 pm, Vinegar Tasters <[EMAIL PROTECTED]> wrote: > I can understand the Android tries to be one operating system on > multiple mobile devices (and their associated chips and CPUs) using > java as an intermediate compatibility layer. However, as many people > found out wish java, javascript ecmascript, python, and other > interpreted languages, they are slow, too slow for cpu intensive > applications like 3D apps (including games), apps needing lots of > calculations (lots in this group like software based movie players and > other things). I think in order for android to succeed it needs to > basically go the pedal to the metal route and simply offer different > SDK for different mobile devices that use different cpu chips. This > way people can program in C or C++ or even assembly language to get > the maximum out of the phone. admit it, most java apps on mobile > phone are too damn slow, and given that the cpu technology in mobile > phones are usually many times slower than desktop versions (in order > to save costs and power), this is a very serious problem. another > way is to just get android and the OHA to simply choose what chips > they support (the faster the chip the better) and develop an OS around > it. You don't find any java applications or games in the marketplace > that people buy for their desktop simply because they are sluggish > compared if you program in C or C++ or even assembly. This is partly > why flash succeeded whereas java applets failed, because flash is fine > tuned to run at full speed of the chip underneath, and there are > multiple versions of flash for multiple OS and chips. I won't go into > flash apps being compiled scripts (yes they are compiled, but faster > than java applets, but you still don't buy flash apps in stores, only > c and c++, or assembly apps), but the main point is that when you go > closer to the metal, and offer direct access to the hardware, the > better apps and chance for success there is for it. So maybe google > can wake up and offer choices. Java based sdk for casual stuff, and C > or C++ based sdk for people who want access to the hardware without > going through an intermediate layer like java. The Android OS should > not be java based, but should be in assembly or C. If it is java > based, it may doom like most people using mobile phones these days > don't buy java based mobile apps. I have nothing against java, just > interpreted stuff that are slow, even if it is "compiled at runtime". > I only wish for options for developers to get to the metal directly. > Because nothing compares to having access to the chips directly and > not through interpretation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
