The interesting bit is how they plan to do the TV integration. They gave no clues in the presentation as far as I could see. I suppose in the US there are some large providers (Comcast, DirecTV and so on), but where I'm at I use an IP-tv provider that really stinks (I cannot even physically get cable or satellite to my home), and would switch instantly if Microsoft signed a deal with something half-decent in IPTV.
Very interested to see them reveal what their "global" plan for TV/Entertainment is. A limited deal with one provider in the US (and a few select sports leagues in the US) would feel like a big meh on the rest of the planet.
This would be great if it wasn't for the fact that during the last decade(s) people have been fitting multi-socket halogen fixtures instead of single bulb standard socket fixtures in their homes. I'd definitely love having an app-controlled lighting system, but it would have to be much more flexible than just a bulb or single socket solution. For light fixtures with several low power halogen lights I'd have to hide the control unit somewhere before the power is split to the individual halogens, i.e. somewhere in the fixture or as a special lightswitch (essenially then a controllable dimmner switch). All the light fixtures that already have dimmers would have to go the same way: the wheel dimmer would have to be replaced by one that can be controlled by the app.
As long as I can dim 3 out of 4 lights but still have to get off my ass to go turn down the fourth light (at the same place where I could dim them all), there is very little gain. As soon as someone offers a simple solution that is expandable to existing switches, multi-socket fixtures and so on, i.e. beyond standard bulb/socket then I'm in.
This research doesn't change that. What parallel programming is about, is currently three steps 1) find parts of code that can execute in parallel (reasonably simple), 2) make sure there is no shared mutable state (hard), 3) make correct threading implementation (tedious
The problem with todays (OO/imperative) languages and tools is that it is exceedingly hard to make sure that state isn't shared. It is also very hard to test for, and find bugs related to shared state. This research helps with step 2. You still have to figure out where these boundaries are, but you can make sure it is correct, by letting a compiler check this for you. It can also help you with step 3, but if your assumptions are correct that isn't hard in current tools, just tedious. Things like TPL and PLink have greatly simplified step 3), but what I assume MS have found out is that with such power to parallelize, developers are spending more and more time in step 2, thus gaining very little.
"I've seen it. It's rubbish." -- Marvin the Paranoid Android