My criticisms were stated in past tense and referencing the response I was going to write. But I just included them as reference points highlighting the different "meta" levels we were addressing. I don't intend to defend those criticisms because, as you rightfully point out, they are irrelevant given the counterpoints from the point of view you presented.
At the moment, we don't know whether or not "reality" has discrete > timesteps [1]. I think we don't know whether time exists in the first place. (if we're going to talk about executing computation with assuming that time does not exists (and in what way does it not exist?) we should *definitely* fork and change the subject line content :D) 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. Either way, as I warned, we just disagreed on our axioms, I can't argue against it, Godel proved it is impossible :D >> But, without invasive code changes or some other form of cheating (e.g. >> global reflection) it can be difficult to obtain the name of an actor that >> is part of an actor configuration. > > > Again, this is ignorance of the power of Object Capability and the Actor > Model itself. The above is forbidden in the actor model unless the > configuration explicitly sends you an address in the message. My earlier > comment about Akka refers to this same mistake. > I am not ignorant of object capability models, nor of actors model, and > repeated accusations of ignorance are a little irritating. I do not > encourage 'cheating' of the mentioned form. I am, rather, saying that this > is one of those problems that people tend to solve by working *around* the > model, rather than with it. I did not attribute ignorance to you personally. I attributed ignorance to the attempt of obtaining a name of an actor in ways not allowed by the actor model (hence I wrote "this is ignorance", and not "you are ignorant"). The fact that people work *around* the model does not make it a good idea, especially since they don't realize what they are giving up in return. I guess part of responsibility for this behavior could be the fault of the model, which is, I think, one of the things you've been highlighting. I'm not dismissing those highlights. I intend to think of how the model can do better to address them. For example, you also want "symbiotic autopoietic and allopoietic systems" > and "antifragility", and possibly even "object capability security". Do you > deny this? But you should consider whether your wants might be in conflict > with one another. And, if so, you should weigh and consider what you want > more. But I am not aware of any sound argument that will take you from "this > model works just like our universe" to "this model is usable by > collaborating humans". For example, it would be difficult to debug and develop actors in systems > that you do not have global authority to restart, without hacking the > model. (This is the 'process control' issue I mentioned earlier.) 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. So, I'm familiar with constraints of real world requirements. There are caveats, and at first glance, many would be hesitant to call it an actor configuration, but it works on actor principles, so I know it's possible to do. A lot of the caveats have to do with addressing many of the concerns you've brought against the actor model, so it's good to hear what matters, so that those concerns could be better addressed in future such systems. We cannot fight physics, because physics will ruthlessly violate our > abstractions and render our programming models unscalable, or > non-performant, or inconsistent (pick two). > But we want programming to be easier than physics. 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. Well, it seems the Universe doesn't care, and we're stuck describing it in the simplest way that generations of geniuses and hard working non-geniuses have been able to come up with. Whatever happened to the pursuit of "Maxwell's equations for Computer Science"? "Simple" is not the same as "easy". We need composition (like Lego bricks), integration (without 'impedance > mismatch'), open extension, and abstraction (IMO, in roughly that order) We are here... talking about this.. 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.. via physics. On Fri, Apr 12, 2013 at 3:30 PM, David Barbour <[email protected]> wrote: > On Fri, Apr 12, 2013 at 11:07 AM, Tristan Slominski < > [email protected]> wrote: > >> my main criticism of Bloom/CALM was assumption of timesteps, which is an >> indicator of a meta-framework relying on something else to implement it >> within "reality" >> > > At the moment, we don't know whether or not "reality" has discrete > timesteps [1]. I would not dismiss a model as being distinguishable from > 'reality' on that basis. A meta-framework is necessary because we're > implementing Bloom/CALM not directly in reality, but rather upon a silicone > chip that enforces sequential computation even where it is not most > appropriate. > > [1] http://en.wikipedia.org/wiki/Chronon > > >> ; and my criticism of Lightweight Time Warps had to do with that it is a >> protocol for message-driven simulation and (I think) actors are minimal >> implementors of message-driven protocols [from edit] >> > > This criticism isn't relevant for the same reason that your "but you can > implement lambda calculus in actors" arguments weren't relevant. The > properties of the abstraction must be considered separately from the > properties of the model implementing it. > > It is true that you can implement a time warp system with actors. It is > also the case that you can implement actors in a time warp system. Either > direction will involve a framework or global transform. > > >> >> I think you and I personally care about different things. I want a >> computational model that is as close to how the Universe works as possible, >> > > You want more than "close to how the Universe works". > > For example, you also want "symbiotic autopoietic and allopoietic systems" > and "antifragility", and possibly even "object capability security". Do you > deny this? But you should consider whether your wants might be in conflict > with one another. And, if so, you should weigh and consider what you want > more. > > I believe they are in conflict with one another. Reality has a lot of > properties that make it a difficult programming model. There are reasons we > write software instead of hardware. There is a related discussion "[fonc] > Physics and Types" in 2011 August. There, I say: > > > Physics has a very large influence on a lot of language designs and > programming models, especially those oriented around concurrency and > communication. We cannot fight physics, because physics will ruthlessly > violate our abstractions and render our programming models unscalable, or > non-performant, or inconsistent (pick two). > > But we want programming to be easier than physics. We need composition > (like Lego bricks), integration (without 'impedance mismatch'), open > extension, and abstraction (IMO, in roughly that order). So the trick is to > isolate behaviors that we can utilize and feasibly implement at arbitrary > scales (small and large), yet that support our other desiderata. > > > As I said earlier, the limits on growth, and thus on scalability, are > often limits of reasoning or extensibility. But it is not impossible to > develop programming models that align well with physical constraints but > that do not sacrifice reasoning and extensibility. > > Based on our discussions so far, you seem to believe that if you develop a > model very near our universe, the rest will follow - that "actor systems > will shine". But I am not aware of any sound argument that will take you > from "this model works just like our universe" to "this model is usable by > collaborating humans". > > > > a minimalistic set of constructs from which everything else can be built >> > > A minima is just a model from which you can't take anything away. There > are lots of Turing complete minima. Also, there is no guarantee that our > universe is minimalistic. > > > > Anything which starts as "synchronous" cannot be minimalistic because >> that's not what we observe in the world, our world is asynchronous, and if >> we disagree on this axiom, then so much for that :D >> > > I believe our world is 'synchronous' in the sense of things happening at > the same time in different places. I believe our world is 'synchronous' in > the sense that two photons pointed in the same direction will (barring > interference) move the same distance over the same period. If you send > those photons at the same time, they will arrive at the same time. > > It seems, at the physical layer, that 'asynchronous' only happens when you > have some sort of intermediate storage or non-homogeneous delay. And even > in those cases, if I were to model the storage, transport, and retrieval > processes down to the physical minutiae, every micro process would be > end-to-end synchronous - or close enough to reason about and model them > that way. (I'm not sure about the quantum layers.) > > Asynchronous communication can be a useful *abstraction* because it allows > us to hide some of the physical minutiae and heterogeneous computations. > But asynchrony isn't the only choice in that role. E.g. if we model static > latencies, those can also hide flexible processing, while perhaps being > easier to reason about for real-time systems. > > >> >> But, without invasive code changes or some other form of cheating (e.g. >>> global reflection) it can be difficult to obtain the name of an actor that >>> is part of an actor configuration. >> >> >> Again, this is ignorance of the power of Object Capability and the Actor >> Model itself. The above is forbidden in the actor model unless the >> configuration explicitly sends you an address in the message. My earlier >> comment about Akka refers to this same mistake. >> > > I am not ignorant of object capability models, nor of actors model, and > repeated accusations of ignorance are a little irritating. I do not > encourage 'cheating' of the mentioned form. I am, rather, saying that this > is one of those problems that people tend to solve by working *around* the > model, rather than with it. > > The fact is that people work around models to solve lots of problems. E.g. > I'm sure you've stopped and restarted actors systems without explicitly > modeling 'stop' and 'restart' messages. Any such workaround should be > counted as a mark against the model. For example, it would be difficult to > debug and develop actors in systems that you do not have global authority > to restart, without hacking the model. (This is the 'process control' issue > I mentioned earlier.) > > >> >> However, you do bring up interesting meta-level reasoning complaints >> against the actor model. I'm not trying to dismiss them away or anything. >> As I mentioned before, that list is a good guide as to what meta-level >> programmers care about when writing programs. >> > > All programmers are 'meta-level programmers' with the meaning you're > giving the phrase. They work at least from from the high level "meta" view > of a text editor or IDE. The distinction is unnecessary. > > >> It would be great if actors could make it easier... >> > > Yes, it would. > > >> Which brings me to a question. Am I the only one that loses track of >> which meta-level I'm reasoning or is this a common occurrence Bringing it >> back to the topic somewhat, how do people handle reasoning about all the >> different layers (meta-levels) when thinking about computing? >> > > I don't remember a time when I had difficulty reasoning about multiple > levels of abstraction at once. I think most people can do it; massive > parallel processing is what our brains do, after all. Of course, the > requisite knowledge isn't born into my head; I had to learn the layers, > abstractions, and architectures. I've also gained a habit to structure my > systems with such reasoning in mind. > > I expect you do it, too, whether or not you are conscious of it. If you > use actors for a RESTful system, for example, you'll probably reason with > various RESTful properties and not just at the 'physics view'. > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
