WebOS is interesting in that it is a JavaScript front-end to C code.
This got me thinking about Android Wear and what I view as it's greatest mistake... the use of Java.
Virtual Machine people kind of go on and on about efficiency but in the end, VM's are just not as efficient as C. One of the major problems is garbage collection and the usage of cache. Not only does GC cause pauses, but the nature of how data storage is created and moved around means that their is no programmer control over data location. Essentially data is in random locations and this causes caches to be less effective.
I'll leave aside the problems of JITing as Android L is abandoning it because of battery life issues and switching to Ahead of Time compilation instead, which has its own set of issues.
My point is that Java has proven sub-optimal on a phone... why in the world, did they put it on a watch?
Watches are very resource-constrained. Small RAM, small storage, small caches and tiny, tiny batteries. This will hold true for several years. How does one make significantly sized apps in that environment? Most of the Googlers are too young to remember this, but Microsoft solved this problem many years ago. You see Office was becoming too fat for the amount of memory that was affordable at the time. Microsoft was actually rather competent back then and came up with an interesting solution. You see, for macro programming capabilities, Office already had a BASIC engine. They modified their C compiler to produce the byte code used by the BASIC engine. They used this feature on code that was not speed critical. Because the byte code had much more powerful instructions than machine code, the overall size of Ofiice was greatly reduced. Eventually they released the compiler technology to third parties. Properly used, it was quite effective.
This is why I find the LG watch so potentially interesting. Smartwatch apps simply should not be CPU intensive... there is little enough battery life there to do minimal things and still make it through the day. A watch app should really only be gluing together watch APIs (written in C) and data to and from the outside world (likely through a cellphone). A dynamic language is perfect for this. The OS itself should of course be written in C.
Some implementation ideas. The programs can be translated to byte code before being stored on the watch. The language should use an interpreter loop, not an AOT. While the interpreter loop is slower, that's not the point here... it's just glue. The interpret loop interacts well with cache. Byte code (as Microsoft has shown) is much more compact than real machine instructions. One will need to be very careful about Garbage Collection, with reference counting, not being out of the question. (Reference counting, while it has flaws, doesn't have the annoying pauses one sees on Android, or really any interactive usage of Java or .Net languages. There are very good reasons why Python still uses reference counting.)
