I always miss a few when making such lists. The easiest way to find new "good questions" is to try finding models that address the existing questions, then figuring out why you should be disappointed with it. :D
On Sun, Apr 14, 2013 at 9:55 AM, Tristan Slominski < tristan.slomin...@gmail.com> wrote: > Impressive. But with Turing complete models, the ability to build a >> system is not a good measure of distance. How much discipline (best >> practices, boiler-plate, self-constraint) and foresight (or up-front >> design) would it take to develop and use your system directly from a pure >> actors model? > > > I don't know the answer to that yet. You've highlighted really good > questions that a "pure" actor model system would have to answer (and I > added a few). I believe they were: > > - composition > - decomposition > - consistency > - discovery > - persistence > - runtime update > - garbage collection > - process control > - configuration partitioning > - partial failure > - inlining? (optimization) > - mirroring? (optimization) > - interactions > - safety > - security > - progress > - extensibility > - antifragility > - message reliability > - actor persistence > > Did I miss any? > > On Sat, Apr 13, 2013 at 1:29 PM, David Barbour <dmbarb...@gmail.com>wrote: > >> >> On Sat, Apr 13, 2013 at 9:01 AM, Tristan Slominski < >> tristan.slomin...@gmail.com> wrote: >> >>> I think we don't know whether time exists in the first place. >>> >> >> That only matters to people who want "as close to the Universe as >> possible". >> >> To the rare scientist who is not also a philosopher, it only matters >> whether time is effective for describing and predicting behavior about the >> universe, and the same is true for notions of particles, waves, energy, >> entropy, etc.. >> >> I believe our world is 'synchronous' in the sense of things happening at >>>> the same time in different places... >>> >>> >>> It seems to me that you are describing a privileged frame of reference. >>> >> >> How is it privileged? >> >> Would you consider your car mechanic to have a 'privileged' frame of >> reference on our universe because he can look down at your vehicle's engine >> and recognize when components are in or out of synch? Is it not obviously >> the case that, even while out of synch, the different components are still >> doing things at the same time? >> >> Is there any practical or scientific merit for your claim? I believe >> there is abundant scientific and practical merit to models and technologies >> involving multiple entities or components moving and acting at the same >> time. >> >> >>> >>> I've built a system that does what you mention is difficult above. It >>> incorporates autopoietic and allopoietic properties, enables object >>> capability security and has hints of antifragility, all guided by the actor >>> model of computation. >>> >> >> Impressive. But with Turing complete models, the ability to build a >> system is not a good measure of distance. How much discipline (best >> practices, boiler-plate, self-constraint) and foresight (or up-front >> design) would it take to develop and use your system directly from a pure >> actors model? >> >> >> >> I don't want programming to be easier than physics. Why? First, this >>> implies that physics is somehow difficult, and that there ought to be a >>> better way. >>> >> >> Physics is difficult. More precisely: setting up physical systems to >> compute a value or accomplish a task is very difficult. Measurements are >> noisy. There are many non-obvious interactions (e.g. heat, vibration, >> covert channels). There are severe spatial constraints, locality >> constraints, energy constraints. It is very easy for things to 'go wrong'. >> >> Programming should be easier than physics so it can handle higher levels >> of complexity. I'm not suggesting that programming should violate physics, >> but programs shouldn't be subject to the same noise and overhead. If we had >> to think about adding fans and radiators to our actor configurations to >> keep them cool, we'd hardly get anything done. >> >> I hope you aren't so hypocritical as to claim that 'programming shouldn't >> be easier than physics' in one breath then preach 'use actors' in another. >> Actors are already an enormous simplification from physics. It even >> simplifies away the media for communication. >> >> >> >> Whatever happened to the pursuit of "Maxwell's equations for Computer >>> Science"? "Simple" is not the same as "easy". >>> >> >> "Simple" is also not the same as "physics". >> >> Maxwell's equations are a metaphor that we might apply to a specific >> model or semantics. Maxwell's equations describe a set of invariants and >> relationships between properties. If you want such equations, you'll >> generally need to design your model to achieve them. >> >> On this forum, 'Nile' is sometimes proffered as an example of the power >> of equational reasoning, but is a domain specific model. >> >> >>> >>> if we (literally, you and I in our bodies communicating via the >>> Internet) did not get here through composition, integration, open extension >>> and abstraction, then I don't know how to make a better argument to >>> demonstrate those properties are a part of physics and layering on top >>> of it >>> >> >> Do you even have an argument that we are here through composition, >> integration, open extension, and abstraction? I'm a bit lost as to what >> that would even mean unless you're liberally reinterpreting the words. >> >> In any case, it doesn't matter whether physics has these properties, only >> whether they're accessible to a programmer. It is true that any programming >> model must be implemented within physics, of course, but that's not the >> layer exposed to the programmers. >> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
