Coincidentally, I now have 9 followers and am following 199 artists on Spotify! And my current profile was created in 2009.
Wesner Moise - previously a top blogger, now resurrected from deep sleep. I'll follow...
This pattern looks cool. I'm going to have a close look at this when doing the next C# project! Thanks for the tip!
Indeed, this is a very cool series of demonstrations.
The F# type provider feature is really blossoming under the open source movement.
In my last project I could have used the Type Script / FunScript type provider.
@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.
Jan 17, 2013 at 7:39 PM
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.
Jan 16, 2013 at 3:54 PM
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.