@joe hoag: With respect to P2P, I'm not sure, my thought was just that actors in different run-times could perhaps talk to eachother since access to state happens through methods (or events), so the state itself can be locally shielded. Therefore calling an "external actor" would be analogous to calling a (Web) [Service] method. How such a P2P protocol for talking between actors would look like I don't know; it's just a vague idea at this point. But in the WS realm there are concepts like Web Service discovery. So why not a similar concept for distributed actors (whether a peer happens to be a node in a cloud datacenter, a cellphone or a workstation)? But I'm new to actors.
Another question is if you can dynamically discover actors and their methods - as if they were Web Services. Perhaps this could be coupled with F# 3 type providers via an actor type provider to "dot into" actors, their methods (or events) and the returning state.
In this open world, perhaps you can even allow your actors to interact with "foreign actors" - other applications in a truly internetworked way - and perhaps associate billing semantics to method calls or data and CPU usage.
Mesh into that P2P actors and this will be quite the interesting creature.
It could also turn into a brittle beast perhaps - when API's change in an open world and things start to break - transitively.
I wasn't bothered by "magic strings" although you could perhaps use C# 4 dynamics but not sure I'd prefer that.
I like the story about Rx integration and lifting objects to the cloud and can see why that is appealing. By the time you have a cloud backend I'm probably ready play with it, after my current project is v1.
It's quite stimulating to think about wat kinds of applications one might build with this technology.
Say, how about a P2P backend as well? - Hey, Windows has P2P built-in with PNRP.
I do wonder about deep immutability. It seems like freezeable objects and collections are generally a nice paradigm but in particular domain classes are painful to make freezable and edit without some language support. Say you want to either change a.b.c or get a new version of a with a new b with a new c, then you could have operations for that ("example syntax")
var x = a.b.c <- x // new immutable version
var y = a.b.c := x // new mutable version
y.b.c := z // destructive update of mutable version
a.p <~ b.x + c.x // a reactive expression propagated to a.p (binq?)
And how about having time or cardinality buffering constraints on properties... select back in time? See properties as cursors in temporal collections? Automatic persistence to versioned db? Capture and replay user interface session from "tape"?
Is there a language waiting to be conceived with even tighter integration for time, immutablity, mutability, async, push, pull, dependency properties, etc. with the benefit of hindsight?
Ahh well at least we now have both great libraries and good language support.
There are also some immtuable F# collections and it would be interesting to compare to those.
I like the builder pattern - not that it's necessary but the optimization it affords. It's also interesting to hear how much defensive coding is inside VS around collections. Immutability where possible just gives peace of mind and static guarantees. It is almost like dependent types where you can express a value constraint statically.
The thing about sharing (and deep immutability) was also interesting, it kind of reminded me of smart pointers but it could have been expanded further by Erik.
It seemed like there was material enough for more talk but this was fun.
There's some people at MIT that appear to think that the abstractions will break down and we need to program in something like RALA http://rala.cba.mit.edu/ for optimal performance on future hardware - but let's hope not.
I want to apply graph databases for program representation and querying. Doing semantic analysis via graph queries. Represent entire software projects, and revisions, in a graph database. Have semantic analysis be graph enrichment. Same datastructure. The graph can also capture lexical aspects like whitespace, tabs and newlines.
The now defunct Oslo project appeared to go in that direction.
With MSR Nyad, MSR Trinity, Datomic, Gremlin, Star Dog etc., it appears the world is speeding towards a graph future, we "just" need optimal efficiency along with the optimal flexibility of graphs.
I would be disappointed if Windows 9 did not do something for the desktop now that the tablet UI is a done deal. But it's understandable that they couldn't overhaul the desktop as well in the same timeframe.
Great video. Enjoyed it a lot. WRT is a really great story for developers.