fair enough :D
On Sun, Apr 14, 2013 at 4:49 PM, David Barbour <dmbarb...@gmail.com> wrote: > 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 > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
