The Next Step for Social Sites

I don't believe "data should be free", but I do believe you should control your own data. On the technical side, there's the notion of anonymous capabilities (why do we still have voter fraud in America and libraries that know which books we borrowed after we have returned them?). Providing a programming (vs crypto) framework for obligations and anonymous capabilities would be amazing - but why, as a Netflix user, do I have to struggle to grab my movie ratings before I can write a rating algorithm based on how I watch movies? Before adding sophisticated security, I'm asking for basic functionality for my data!

Data may or may not want to be free, but it certainly wants to travel. Dapper shows that public webpages are just data we can manipulate, but I found these tools difficult to use in practice, and in general, there's probably already enough interest to make a concrete widget by the time I think of something. For example, when setting up this blog, I wanted the same movie and books roll as on my facebook account. This is tricky because Facebook requires logging in to grab data, and Blogger does nothing to simplify integrating the data in, especially live data with potentially bidirectional relationships.

Boding well, there has been a big push for OpenID to allow single registration across multiple sites that support it. I'm more inclined towards a browser integrated versions of something like CardSpace (I believe this basic idea originated from MIT but cannot find the reference). However... what about the data? I want my Picasa data on my cellphone and laptop, online or offline, and I want to be able to have a feed on my blog or facebook profile. Depending on which app I'm using, I'll want to interact differently in terms of actions and granularity , and have new data propagate (hence lenses).

I suspect part of the future draws of social nets, and especially new ones, is the ability to not have a lot of pain in migrating data. Once more and more apps start supporting that, people will only move to ones that support that (no more retyping data unless necessary!), causing an avalanche. Of course, there's the question of legacy juggernauts - but I suspect "the social" will be bigger than the sum of its parts for this reason, and people will be annoyed with limitations of monolothic systems. The only party I see losing from this is Facebook as it is the resident Microsoft - but compare it to a iphone menu between Flickr, Blogger, and Hasbro. Hello, Android.

ps: I'm curious as to future interplay with the upcoming iPhone native code SDK and Android - a VM over both, and JS + Gears/AIR would be an interesting language target.

Buzz Buzz Buzz

I took a few weeks off to visit the family in RI, hang out in NYC, and make some progress on my mixed imperative/functional reactive programming paper, but then came back for some stimulating times. While most PL researchers in the bay area this past week were at POPL, a few slunk away to our (unfortunately) co-scheduled soup to nuts parallelism academia+industry retreat in Tahoe. Beyond experimenting with elongated, controlled falls down the slopes, I heard a few interesting perspectives on the issue. I didn't sign any sort of NDA, but suspect anonymity is the way to go - instead, imagine these as Sun, NVidia, Microsoft and Intel level superstars as well as academics working on topics from mixed vector/threaded architecture to real-time music synthesizers to black hole simulators to auto-tuners to static race detection.

I found the following tidbits neat:

• We're in a multicore world for the next 5 years - infrastructure to be manycore after that
  
• New features need economic motivation (ex: hw performance probes for non-scientific hpc uses)
  
• Is parallelism the problem, or IO?
  
• Corollary: easier to augment (ex: machine learning optimizers) than restructure
• Languages
  
• have ~1 devoted chief designer
• break the generation rule for DSLs
• have a progression from frameworks to DSLs
• can this be automated?
• interesting to see a percentage breakdown between developers of frameworks, and developers using frameworks
• out of these, how many can see up and down the abstraction stack?
• ... and how far?
  
• GPLs follow the generation rule
• feature view:
  
• what is the roadway for feature cross-pollination?
• everyone wants generics/parametric polymorphism now - what parallelism primitives will be mainstream tomorrow? STM, textual barriers, maybe parallelism, ...
• GPGPU is out, GPU Computing is in: don't fit general constructs on the gpu, but find novel tasks appropriate for gpu constructs
• Corollary: layers dealing with explicit parallelism are already fairly low-level and thus potentially needs this level of knowledge and control
• In practice, auto-tuning is effective enough to provide almost a magnitude of performance gains
• Layers concerned with responsiveness (music, UI) and performance (most hpc) are often separate
  

I received primarily positive responses to my parallel browser scripting language proposal poster, and got to meet Jan Maessen of Fortress fame (first met him when he gave a fun talk at NEPLs awhile back on associativity/commutativity type declarations for improved composition and parallel scheduling). Fortress is pushing as much as it can into the libraries, including support for parallelism, so they're dealing with a lot of the problems we ran in to with Flapjax, and I benefited from hearing about alternative PLT perspectives on it. Somehow Chris steered the conversation towards Kahn processes, so good times.

This week: paper writing, browser benchmarking & road-mapping, and movie machine learning side project.