View Single Post
Posts: 25 | Thanked: 22 times | Joined on Dec 2009
#45
Originally Posted by Flandry View Post
What? Paranoid i may be, but disingenuous i'm not (and i don't appreciate you claiming i am if you don't actually read my argument).
I did indeed read your arguments. I came to this thread after reading this one in which you make several comments along those lines, such as this on Java (and, given the context, Javascript):

Originally Posted by Flandry View Post
Not having java supported in my mind avoids diluting the quality of available software by having cheap & dirty java versions of apps pop up that never work as well as the alternatives would--alternatives that either won't get made or won't get refined because the nasty java version is "good enough".
But I'll grant you that I guessed incorrectly and will take you at your word that battery life (or device resources in general) is your first concern, the quality of the software ecosystem is second and anything else ranks below those two.

In which case, I think you have little to worry about. For many applications, interpreter overhead really can be ignored --- for example, updating a weather or stock widget or any other kind of status widget; simple user interfaces for things like media players; small-scale file and email management; system maintenance tools; instant messaging; dictionaries; etc. Yes, they can be coded poorly, but so too can native apps. (And some of the core apps on the N900 have already proved this! --- though I should note, I'm still waiting on my N900 to arrive.)

For other applications (particularly games, but also many other apps) concerns about the interpreter's performance will swamp any concerns about battery life, so people will be forced to write natively (or, more likely, not at all).

But instead of batting fuzzy opinions back and forth, you can partly test this out for yourself. Find applications that have been implemented as both a web application and native application (to an equal standard, of course), run them both on your N900 for a long period, and compare the effect on battery life. Even better would be to cut some code yourself, so that you can guarantee the applications are as similar as possible. My guess is that those cases in which the web application depletes the battery faster will also have woeful performance in comparison to the native app.

Originally Posted by Flandry View Post
Furthermore, i don't believe the demographic you claim to represent is significant enough to matter if the WRT absorbs resources (whether developmental or on the device itself) that prevent the next maemo device from being less svelte and having a longer battery life (as described in my earlier post), which would exclude the much, much larger demographic that buys iPhones but doesn't want to develop in any way.

Simplified venn diagram of the point:
(((System Language Developers) WRT developers) smartphone users)
where # smartphone users >>> all developers

Pappy taught me there's no such thing as a free lunch. My preference is for efficiency over having WRT, and i think that's also most important for Maemo's growth (by the metric of device sales and satisfied users, not # apps in repo).
Are you saying that device sales and satisfied users are completely unrelated to the number of repo apps available? I actually hope you're right (but I have very different motivations).

Your Venn diagram also suggests that anything WRT developers can do, native developers can do too, which I doubt very much. More than that, you seem to be suggesting that any useful thing WRT developers would do, a native developer will do (so long as WRT developers don't exist), which is clearly false.