Future of Personal Computing and Prospective Students

1. Lethevert is turning Flapjax Japanese.

2. I gave a lightning talk (scheduled 8 minutes, cut to 5) today to this year's admitted perspective Berkeley graduate students with an interest in programming systems on why we're thinking about redoing the whole client web stack, albeit not how.

I'm really a language guy, and one of the big lessons is that it takes a generation or dimension shift for new ones to come into acceptance. We're very close to one of those moments, and, it ain't because of breaking ground in language research: it's because of a combination of Bell's Law and the power wall forcing hardware folks to do something they've been putting off since the advent of the desktop. Consider the following:

• Mobile single core future: Intel's more traditional pocket device chipline -- Atom, Moorestown -- for the next couple of years will take our iPhones to the Pentium M and beyond. That's a 5 year step backward for personal devices.
• Recent multicore mobile devices:
  
• CPU+GPU player
  
• Sony XPeria AKA iPhone Killer
• Upcoming ARM Cortex, ...
  
• Output:
• foldable epaper
  
• mini projectors
  
• Input:
• laser keyboard with auditory feed back
  
• inaudible speech recognition
  
• high (low?) frequency sound triangulation based stylus
  
• Apple bought FingerWorks and their TouchStream keyboard -- why not bring a full multi touch sensor based keyboard back, but on a display a la iPhone with foldable epaper display?
  

Everyone's come to grips with the fact that HP has been selling way more laptops than desktops for awhile now. Bell's law tells us that as soon as it is economically feasible to go lower, we will, and that this new class of devices will upset the one above it. In terms of single cores, not happening, but once you have multicore (and only a few increments of multi takes you to many), this is plausible. Looking the the NVidia and XPeria devices, I just hadn't realize we're already started to see this happening.

I didn't get to deliver the punchline in my talk as clearly as I would have due to the time crunch: part of the upset must include the software, because the individual cores will not be competitive. Existing software will not work better on more but slower cores. As the browser will likely be the chief delivery mechanism for content, it is one of the biggest targets for optimization. Lexing, parsing, JITing, rendering, computing, querying, saving, and loading must all be rethought. It will likely be hard to write programs in existing languages -- JavaScript 2.0, CSS, etc -- that work well in this world. For example, the button rollover effect in Pandora is choppy on my Pentium M laptop, yet there is little reason for the individual button interactions to be computed sequentially. JS has closures and thus actors and an encodable notion of concurrency, yet it is hard to prove strong isolation (is that the term?) for such encoded things that would allow parallel execution. Explicitly providing concurrency controls with desirable atomicity properties -- not necessarily for imperative code -- makes a lot of sense for largely reactive ( event oriented ) programming rather than the current anything-goes system. Further, we need to support web and application abstractions and metaphors. At this point, as academics, we might look more than a year or two ahead of us and see the opportunity for rearchitecting the stack in a relevant way.

Back to paper revising and proving things about continuous and monotone lambdas.