Re: Can someone tell me why N900 and not Android?
 

Here's a good question for the community... Comparing the executable code strategies for Android and Maemo, which do you think is better? Why?

Android apps (AFAIK) are written in Java with (hopefully) a Java JIT compiler to compile the bytecode, whilst maemo apps are coded in whatever, and compiled to native ARM code. Which is the better strategy? Why?

I'm genuinely interested to hear what you think!

}:^)~

Re: Can someone tell me why N900 and not Android?
 

Dalvik (Android's runtime) isn't really Java. It's an optimized subset of Java (they eliminated things that would slow it down).

I'm not sure you can really say which is better. Each one makes it choice based on larger issues than just executable code speed.

Android is designed to run on multiple hardware platforms (the multiple ARM variants, MIPS, x86, etc.). For that to work, while still providing a single user experience, native code just wasn't an option. And, this approach is probably a factor in why we're seeing Android pop-up on so many different devices (official, and unofficial). Why bother if you can't run any apps on it? or if you have to get vendors to port their apps to N different CPUs.

Maemo, on the other hand, only runs on a single specific hardware design. It doesn't need that support for multiple platforms. On the other hand, that also means it doesn't have the benefit of running on multiple platforms from multiple vendors. And, its approach would be awkward at best (for the consumer market) if it was deployed on those same platforms as Android.

So, one approach gets you CPU flexibility/independence and proliferation. The other approach gets you speed and maximum hardware utilization. Each one fits the higher goals of the people who made that platform. You can't really say which is better without addressing which of those higher level goals is better ... which, IMO, isn't an answerable question. It depends on what you/they want.

Re: Can someone tell me why N900 and not Android?
 

I didn't mean that I don't see the point of the d-pad in and of itself. You quoted me out of context. People seem to love to do that on this forum. Quote someone out of context, make them appear to say something they didn't say, and then respond to the thing they didn't say. What's the point?

Anyway, I said I didn't see the point of the d-pad, given that the scrunched up keyboard on the Droid is supposed to suck. So is the benefit of the d-pad worth the trade off of having a keyboard that sucks so badly some reviewers are reporting it's better to just give up and use the onscreen keyboard? There are obviously a lot of touch based phones out there now without d-pads that people are happy with. If both a d-pad and a decent keyboard couldn't be squished together into the Droid's form factor, I would have far preferred a good keyboard.

Re: Can someone tell me why N900 and not Android?
 

Android's trading compatibility and speed for portability. An unwise compromise to make with mobile devices, in my opinion.

Re: Can someone tell me why N900 and not Android?
 

Running at a slower but acceptable speed on more devices versus running at a faster speed on fewer devices makes the latter strategy much more device dependent. If you're the device manufacturer, you can control that but Google must rely on a number of manufacturers using their OS and apps.

Plus, don't forget Moore's law. With faster CPUs the relative speed advantage decreases.

I'm old enough to remember writing in assembler language. If you want the absolute fastest program, it's still the way to go but very few people think it's worth the trouble.

Re: Can someone tell me why N900 and not Android?
 

@johnkzin,

An incredibly insightful and eloquent explanation. Thank you for that (especially the Dalvik bit, which is exciting news to me). But I'm really curious to hear *your* personal commentary regarding the architectural choices upon which each platform is engineered.

PS. Do you know of any dalvik benchmarks that compare execution timings to java/C/etc?

}:^)~

Re: Can someone tell me why N900 and not Android?
 

There are also java bytecode assemblers out there! Though I would imagine that any optimization would have to be time tested on the target platform(s) as the interpreter/JIT could yield very different results across architectures. Still, interesting for eeking out a bit more performance here and there.

}:^)~

Re: Can someone tell me why N900 and not Android?
 

Here's an interesting read on Dalvik. The 'iphone hate' in the last paragraph made me laugh out loud as it comes out of nowhere!
http://www.betaversion.org/~stefano/linotype/news/110/

And here's a link to the wikipedia entry on Dalvik:
http://en.wikipedia.org/wiki/Dalvik_virtual_machine

A good read!

Here's a talk by the creator of Dalvik:
http://sites.google.com/site/io/dalvik-vm-internals

}:^)~

Re: Can someone tell me why N900 and not Android?
 

Dalvik is two things -- a class library (analogous to a J2SE or J2ME implementation -- and Dalvik's doesn't match either), which is where your statement holds true, and the bytecode interpreter, which differs in less clear-cut ways.

The bytecode interpreter differs from many Java implementations because it _is_ a pure interpreter, not a JIT compiler. Also, and most significantly IMO, it's a register-based (instead of stack-based) VM. For those not familiar with this architecture debate, think of RISC/CISC, and don't ask "which is better" unless you like flamewars. :D

Re: Can someone tell me why N900 and not Android?
 

I don't consider it to be an "either-or". I think the best approach is "both".

If I were to win the lottery tomorrow, I'd hire a couple of engineers to take an Android dist. and add something like Cygwin to it (so it uses the Android display model, and not X, but provides API and ABI compatibility with X based applications), and then port GTK+ and Qt to that. I'd add bin-utils, shells, some other programming/development stuff (Sun Java, Python, Perl, Tk, maybe Tcl and Ruby), and a vt100 compatible "droid-terminal". Then I'd port a few common things to it (firefox, thunderbird, mplayer, a few others), and add a "me" account to it. I'd also look into adding the debian style package management to it, for the non-Dalvik apps (and the Ubuntu graphical counterpart, whose name I forget.. starts with an S I think).

That's how I'd approach it ... but I have an anti-X bias that says "it's better to start with the non-X platform and work toward the middle, than to start with the X platform". If I was Nokia, I'd start at the other end of that bias (due to the investment in an X based platform). I'd leverage the work the one guy at Canonical did (porting Dalvik to Ubuntu), and get Dalvik working on Maemo.

Though, the other thing I'd probably do, is see about supporting/leveraging fat binaries (1 executable file with multiple executable segments, each for a different platform). If I could work it into the native tools, it would be the default, with an option to allow developers to narrow it down if they feel it's strictly necessary. That would add some degree of flexibility to the native code developers, as well.

In general, I don't think it's reasonable to make developers or users choose between the two approaches (whether you're talking about Dalvik specifically, or Java generically). Evolution will determine if bytecode apps will do well enough to thrive alongside native apps (and visa-versa). Let the developers gamble, and the users decide. IMO, the OS platform designers job is to enable those two groups, not pigeon hole them.