Thursday, October 16, 2014

Apple iPad/Mac Event

The event was largely a rehash of WWDC with some standard incremental-enhancement product announcements with no surprises.
I killed my live blog notes... just too boring.

There were only two items of note:

1) They've only sold 225 million iPads -- ever -- (2010, 2011, 2012, 2013 and part of 2014).
To put that in perspective. The PC Industry in 2013, a truly down year, shipped 315 million units.
Android shipped 120 million tablets in just 2013.

Forget all about #2 below... see final update.
2) The Mac mini price dropped to $499 and appears to have SSDs... this needs closer examination... but might be worth a look. They are supposed to be available later today. Web site still not switched over, so I'm still waiting for other shoe to drop as it usually does with Apple pricing.

UPDATE: 1:30 Web site now up. The Mac mini SSDs were too good to be true. But it's still an OK upgrade. Probably the only Mac Desktop worth the money. Will need to wait for an iFixit tear down to see if I can upgrade it easily on my own.

UPDATE: 1:39 Apple scandalously is putting 5400 RPM disk drives in default configurations of iMacs. Steer away from these! I thought they would surely stop doing that this time. With the prices they charge, that's just insane. ALL HARDWARE UPGRADES ARE RIDICULOUSLY PRICED!

UPDATE 10/17 19:18 Forget all about #2 above, The Mac mini's memory is not even upgradable.
Apple just doesn't get that systems are getting cheaper and they were already over-priced.

Thursday, October 2, 2014

Why Smartwatch Development Should be in a Dynamic Language

I just ran across this article, talking about LG hedging their Android Wear bets:
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.)

Wednesday, October 1, 2014

Top 10 Reasons Why Microsoft Called the Next Version Windows 10


  1. Apple's been at version 10 for 15 years now... perhaps it's a good place to be.
  2. Ten is the count of new features in Windows 10.
  3. They spent so much time talking about Windows 9, they thought they'd already shipped it.
  4. Apple had already used all of the big cat names.
  5. They wanted a name like MacOS X Mavricks, but Washington state just doesn't have many well know landmarks.
  6. (Related to the last) Windows 10 Space Needle just sounds wrong.
  7. So does Windows 10 Puget Sound.
  8. Because they think it will be lousy and they've reserved even numbered versions for that.
  9. Used Windows Calculator to add 1.














    AND

















  10. Realized that Android, MacOS, ChromeOS and Linux have already taken Windows 9's spot.