Thanks for the link! RDP looks quite interesting, and I'm looking forward to further developments. Some of the space-time leakage problems of the early FRP models have been addressed with Nillson and Hudak's Arrows-based Yampa system; could you use any of this in your Haskell RDP implementation?
Apropos of reactive programming and formal methods for ubiquitous systems, some may be interested in the late Robin Milner's work on what he called the Bigraphical model, which also adresses many of these issues, providing a mathematical foundation for an entirely different (and much more scalable) mode of information processing from the Von Neumann machine which (IMHO) is one of our most fundamental unquestioned assumptions... http://www.cl.cam.ac.uk/archive/rm135/ -- Max On Thu, Jun 30, 2011 at 9:30 AM, David Barbour <[email protected]> wrote: > On Thu, Jun 30, 2011 at 3:13 AM, Chris Warburton < > [email protected]> wrote: > >> On Wed, 2011-06-29 at 11:40 -0700, Alan Kay wrote: >> > The only human artifact that is remotely like this is the Internet, >> which has >> > been able to grow and replace most parts large and small without having >> to ever >> > be stopped. >> >> At the network level we have the Internet, as an 'Intergalactic >> Network', but it is never interacted with directly. Instead it has >> become, in the developed world at least, a ubiquitous communication >> medium *for our devices*. >> >> At the software level we have, for example, Smalltalk. As has been >> mentioned many times before, this is essentially its own network of >> pluggable computers (objects). >> > > The internet is made up of active objects with a high level of concurrency. > If you're searching for analogous software models, don't look to Smalltalk > with its passive objects and control flow. Multi agent systems are a better > comparison. > > We want resilient, scalable, open applications. Consistency, security, > graceful degradation, and behavior during and after partial failures > (disruption, partitioning, node failure, buggy software components) will be > major concerns. Our models for communication, concurrency control, > identification and linking of dependencies, system discovery, and > configuration management are all impacted. > > To be 'eternal', we need runtime upgrade - the ability to upgrade and > modify software components without restarting the whole system. We desire > 'live programming' - ability to upgrade and modify a component without > disrupting active users. > > If a developer must know the entire history of an eternal program in order > to understand its current behavior, that would be a serious obstacle to long > term development. So, after upgrade, the modified system should quickly > reach a state as though it were always using the new code. This has a > profound impact on the use of 'state', and suggests favoring a reactive > programming model that can easily propagate a change. > > Our data models will change over time... but the data models of our > dependencies will change at their own pace. This suggests that we need > effective adapters between data models, such that we can transparently > replace a model with a 'view' of it. I think the distinction between model > and view breaks down very quickly. > > I've been developing requirements, desiderata, and programming models for > open distributed systems programming since 2003, with an emphasis on > real-time systems. The resilience and upgrade requirements for open > distributed systems naturally imply eternal computing. In April 2010, I > finally came up with a model I find extremely promising (though I've only > run it through pseudocode tests). I call it 'Reactive Demand Programming'. I > started to blog the subject in May 2011 [1]. > > >> These are the ideal wearable computer, as they are perfectly > > acceptable standalone machines wherever we are, but when > > we sit at a desk they merge with our office computer seamlessly > > so that we don't have to care about eg. sync issues. > > > I'm also interested in 'pervasive' computing, augmented reality. For > example, consider the ability to take a picture of a printer then drag and > drop a symbol for a document onto it. This would require we identify the > printer by some combination of its image and other indicators for our > location. > > You might check out a language called 'Ambient Talk', designed to support > mobile computing and interaction with the environment. Unfortunately, > Ambient Talk is not designed for security > > My favored model for 'discovery' of the environment and dependencies > involves a network of fine-grained, composable, RDP registries (i.e. a > network of micro-databases). Each can be administered separately, adjusting > the filters and such, and there are separate publish and query > capabilities. The registries are stateless (in RDP, I can replace most state > with 'continuous publish', and simply make disruption equivalent to > revocation). Different registries can represent 'ambient' vs. 'machine > local' vs. 'global' resources (and, appropriately, different levels of > security). Individual users and organizations will tend to maintain their > own registries. > > >> >> Every once in a while we would prune off the dead parts from our >> computers (while the working parts are still running, uninterrupted), >> buy a pack of fresh computer and stick it on. > > > Even if we had easily replaceable computing substance, we should still > expect disruptions. For example, the dead computing element might be the bit > handling the camera or display. > > In 2007, I came up with an idea of declaring dependencies between > components in order to control partial failure: i.e. the creator of A can > declare 'A depends on B'. If B is ever disrupted from A's perspective, then > A also becomes disrupted (drops all communications). If B is ever destroyed > permanently, then A can be destroyed permanently. The idea is to propagate > partial failure to boundaries where developers can more effectively > recognize and handle it. Fallback services or regeneration protocols can be > introduced at those boundaries. This gives us clean failover. Declarative > dependencies can be combined with 'suicide' components (which die on > command) to securely prune old software from a system - i.e. manual memory > management, job control, etc. except controlled by capability security. > > One advantage of these declarative dependencies is that we can derive from > them precisely how much redundancy we actually need in our software, while > recognizing valid sources of disruption. For example, if software component > B has a dependency on camera C, then there is little reason to have > redundancy of B that will survive destruction of C. > > I developed this idea for a variation on actors, years before RDP. But I > believe it still applicable. > > Partial failure, graceful degradation, fallback services and resilience is > something we can achieve in computing much more effectively than in nature. > > Regards, > > David Barbour > > [1] http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/ > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
