The trouble is never with the people who ARE good coders, but with those who aren't. Apple does not have multitasking for the same reason - it's the simple way/euphemism of avoiding calling your developers incompetent (both iOS and Android do plenty of multitasking on system level/their own apps, it's just 3rd parties that they don't trust).

As for python, the concern was the inherent memory overhead (which can then chain-react into resource drain regardless of your good intention and quality code).

You're right there, this is why I don't seriously use Python pretty slow and heavy. It is good for knocking up testcases/prototypes though.

In related news: http://talk.maemo.org/showthread.php...260#post926260

From a desktop developer point of view, I will not write Java code.
There are two reasons for it:
1. I don't like or know Java.
2. I have a lot of C code and C libraries that I use.
If I were to port an application, I would much rather spend a few days making it compatible with a new platform (stuff like screen size, lack of mouse, etc.) than rewrite ALL my code in Java.

And of course, Java is slower than C/C++, which means that more powerful CPUs are needed, which will eat your battery more.

Oh, and one more thing: Most of the cellphones use ARM based CPUs, there is no need to use Java or .NET stuff.

The more I read into this thread the more I realize what Nokia was supposed to do:
1) Buy Palm
2) Release the Nokia N8 with Maemo6 Harmattan (dubbed MaeOS v1.1) which is a blend of Maemo5 and WebOS sometime around June.
3) Successfully create a new OS from Moblin, WebOS and Maemo5 where the project is open source (for KIRF makers/xda-developers) but the Market and Corporate features are available only on phones through commercial vendors (Nokia, HTC, Samsung etc etc).
4) The developer needs to write the App once (and only make minor alterations to port it to make it x86 compatible).
5) The device has all the smartphone features (unlike WP7 who left out Cut/Copy/Paste) and has a really responsive and great UX.
6) Pay the recognized developers from the iOS and Android platforms to port their Apps to the new platform (like Microsoft).
7) Release a Cortex A9 based, 10in Nokia tablet in late October
8) Release a range of smartphones (to vendors/customers) from Nokia (dubbed the P-series, which embraces their Palm acquisition, while also standing for phrases such as Paradise and Perfect)
8) Other OEMs release their smartphones in-line with Nokia for the Christmas season (late November).
9)* And release the successor "Maemo" (no longer Maemo5/Harmattan) project with tools for smartphones, tablets, netbooks, appliances (New Years Eve).
10) Continue on getting all those little bugs fixed, have the "Maemo" platform completely adapted for the next-gen devices (Cortex A9, SGX543, Atom Z6, other Atoms).
11) In 2011, look to have Maemo replace Windows7 on netbooks.
12) Continue in being very competitive and watch Maemo to quickly catch up to Android, looking poised to take on iOS in 2012.
13) Start divulging in making TV + Internet + PersonalComputing = MaeTV.
14) Start making big profits (Nokia and Intel) for all their hardwork in the risky times (Android domination)

*I really dislike the name MeeGo, personally Maemo sounds much better!

IMO they need other vendors from start and they just need these vendors to release meego compatible platforms across whole spectrum of our everyday life. Intel and Nokias ultimate dream come true is that every single equipment from coffee maker to your car and house automatic control system have meego on system level running and they all are connected. Upon meego every vendor adds UI layers what they like but key to success is to have universal communication between every platform. Also most importantly to have platform that is totally open and you are not strictly bind to other company's strategy (e.g. Google android or Facebook from point of fcbk apps). For Nokia keyrole here is that your cellphone is basically your data-center that you carry wherever you go and it identifies.

I see too much people talking here and every other forum about cellphones/smartphones strictly even thought the target for companies is something much much bigger.

As you probably understand, I didn't want this thread to become a flamewar and I was somehow tired of arguing regarding whether meego should have global applications, a central app repository or extremely easy deployment tools. Thus I stopped arguing.

But I just showed this. I'm hopping that this answers the claims regarding vendors that want their own repos, etc, etc... At least it shows that this kind of thinking is soooo 1990s, how a company should think in 2010 and (perhaps most important of all for Nokia) how much publicity and acceptance this kind of thinking gets.

I'd like to end with something like: 'told you so...

At this point, the major factor holding back write-once run-anywhere binaries is that they generally require developers to conform to a particular language.

In my experience developers are EXTREMELY loyal to their respective environments (language and OS) and resistant to change, which is likely why this thread has ruffled more than a few feathers.

Additionally, write-once executables require that developers abandon often very well developed languages that have libraries of code and mature development environments. This is one reason (but only one) perl thrives despite somewhat poor syntax. There is tons of perl code available for re-use and easily accessed.

But there is light on the horizon. NaCL (Google's Native Client, and implemented using LLVM, FWIW) introduces a secure binary format for x86 that doesn't imply a single host language, just that .nexe files are produced. This allows developers to maintain their existing languages, and write code that's guaranteed to run at native speed regardless of the OS -- providing the appropriate compiler and NaCL clients exists.

With the introduction of PNaCL, these binaries can run across x86 and ARM, though as security is a paramount goal of the project, there is a huge speed penalty on ARM due to lack of virtualization instructions.

For tl;dr people: the holy grail of run-anywhere binaries have (nearly) nothing to do with the language, it's about platform/OS abstraction.

What. The. Fortran. The executable binary format is specified by the OS. An ELF binary is an ELF binary, regardless if you wrote it in C, C++, Fortran, Ada or Pascal. The other group is interpreted languages - well cool, but that's essentially just source that is (again) run on an interpreter done in native code (=it's more about distribution than it is about binary format). I already see you smiling, but what about... JAVA ! (and all other bytecode stuff). Well, TBH that link is correlational because of the way Java was born. There is nothing saying you couldn't compile C++ to VM bytecode and there is nothing saying Java (as a language) cannot be compiled to native code (in fact that has already been done).

Ok, so you're ignorant about Java. Fair enough.

But if you're ignorant about it, what do you know that you dislike?

You can use compiled C libraries from Java. Just Google it and lessen that ignorance.

The endless speed debate. Java, on the other hand, offers great ways to optimize your running binary by inspecting it which isn't possible in C++. There are nice Java3D bindings using available 3D hardware so you're left with (real) speed differences when it comes to number crunching. How does that apply to you as a "desktop developer"?

How does the CPU type affect this? How is that relevant?