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
