There is a philosophical sense in which all entities (beings) should be comprehended (not only re-presented) as bundles of actions or “activities.” In turn, every action should be understood as a perception. To that end, Carl Hewitt’s Actor Model has been the obligatory point of reference for any discussion of concurrent computation and concurrent hardware and software engineering. (See: http://arxiv.org/abs/1008.1459 )
There is nothing more to the Hewitt ‘Actor’ than its activities, as Robin Milner correctly recognised from his point of view: “Now, the pure lambda-calculus is built with just two kinds of thing: terms and variables. Can we achieve the same economy for a process calculus? Carl Hewitt, with his Actors model, responded to this challenge long ago; he declared that a value, an operator on values, and a process should all be the same kind of thing: an Actor.” (Robin Milner , Turing Lecture, 1993)
Notwithstanding Milner’s call to see everything as a “process” (aiming at the same level of “completeness of expression” as Hewitt ) he was right in his distillation of the fundamental goal of the Actor model. He was right too in considering it at the same conceptual level as the lambda-calculus and his own process calculus, as a mathematical foundation with intrinsic “homogeneity” and economy of means.
Hewitt himself has repeatedly underlined the fundamental and general character of the Actor Model. Indeed, if we take the formula that “everything is an actor” we should not stop there and assume that Hewitt is proposing only a change in nomenclature, so that whatever we called before an “object” or a “process” should now be called an “actor.” Too many people continue to understand the Actor Model as if Hewitt had been talking the past forty years about “active objects” or “objects with mailboxes,” which is not the case.
By establishing that “everything is an actor” Carl Hewitt is *also* saying (crucially) that a variable is an actor, and he has been sufficiently clear about the notion that it is not the case that an Actor can “hold” or “have” a variable or value. Something very different to “objects,” “processes” or “agents” is assumed in this conception: if there is nothing more to a Hewitt ‘Actor” than its activities, we can say too that a an Actor must be conceived as a bundle of activities (in Hewitt’s terms these would be “messages”).
Regrettably, though, there are also several instances in Hewitt’s work, and particularly in the papers of his collaborators, which diminish and obfuscate the understanding of actors. In “Foundations of Actor Semantics,” for example, William Clinger presented a mechanistic “actor model” with an assumed “global time.” In doing so, Clinger reduced all interaction to “sequencing problems” between the actors and the “flow” of information (as a substance) between the participants of interaction: “The actor model refers to the arrival of a message at an actor as an event. Thus all events in the model are arrival events, and there is no such thing as a sending event.” (Clinger, 1981)
Equally damaging was the work of other researchers who decided to reduce the actors to “reactive” units, only operating when they “receive” a message. For example, in “Actors, a Model of Concurrent Computation in Distributed Systems,” Gul Agha assumes an actors as entities that operate or “process” only as a consequence of “receiving messages” : “An actor may process only those tasks whose target corresponds to its mail address. When an actor accepts a communication, it may create new actors or tasks; it must also compute a replacement behaviour,” (Agha, 1985)
Contrary to these interpretations, as seen from the perspective of “other Actors”—if the figure is admissible—, an Actor is perceived only by its activities (we can call them “messages” if we wish). And all interaction between two or more Actors must be comprehended as an interaction between these bundles of activities (values, operators, etc.)
The later work by Hewitt himself, in particular his paper “Actor Model of Computation: Scalable Robust Information Systems,” – http://arxiv.org/ftp/arxiv/papers/1008/1008.1459.pdf – is so far the best reference. There we find for example the clear statement that : “The following are not required by an Actor: a thread, a mailbox, a message queue, its own operating system process, etc.” (page 3). More decisively, we also learn from Hewitt about the physical concepts he is representing in the Actor Model:
“Interaction creates Reality
“a philosophical shift in which knowledge is no longer treated primarily as referential, as a set of statements about reality, but as a practice that interferes with other practices. It therefore participates in reality. Annemarie Mol [2002]
“Relational physics takes the following view [Laudisa and Rovelli 2008]:
• Relational physics discards the notions of absolute state of a system and absolute properties and values of its physical quantities.
• State and physical quantities refer always to the interaction, or the relation, among multiple systems.
• Nevertheless, relational physics is a complete description of reality.
“According to this view, Interaction creates reality. Information systems participate in this reality and thus are both
consequence and cause.” (page 7)
By losing sight of the actual abstraction level of the Actor Model formulation (i.e. its level of generality, homogeneity and completeness in the theoretical sense underscored by Milner), the statement “everything is an actor” is understood by many as saying “every object is an actor”; and the assumption is automatically (ideologically) made that every object has to be “represented” as an actor, for example by using an “actor-oriented language.”
So the discussions about computational concurrency and the Actor Model dissolves into the “advantages” that an “actor formalism” might have as compared with object or agent-centric representations. People misunderstand Hewitt and in some cases mistreat him as if he were talking nonsense when in reality he is doing an exceedingly patient work trying to extract Computer Sciences from the swamp of Metaphysics. While Hewitt is talking about the Being of the Actors (i.e. the universality of concurrency), misguided commentators only see the “beings” of objects (i.e. the representation of multiplicity and parallelism).
Absurdly, people object to the treatment of concurrency as a general (*universal*) ground of all activity, and in turn this leads to a trivialisation of the discussion. Facing the challenge of universal concurrency in computation and in nature, some people want to discuss only partial, expedient, engineering “solutions,” and ignore Hewitt’s contributions.
It is granted that Professor Hewitt may be failing to convince the computer engineering collective (at least in the discussions I have seen), but he is right in sticking to principles.
In the sense of a positive “proof” the engineers demand and will be only convinced if and when they are presented with a machine or at least a conceptual mechanism (a representation of levers and cogs) embodying the Actor Model. They will not be convinced by a logical language –like ActorScript—no mater how complete it is. (See: http://arxiv.org/abs/1008.2748 )
The nature of things is such that –if I understand the Actor Model correctly—there is no mechanical embodiment of an Actor and it can never exist (by “mechanical” I mean “sequential-parallel”). Or, better said: Hewitt’s contradictors are asking for a proof that the model itself excludes as a proof. Hewitt suggested in a conversation with Erik Meijer and Clemens Szyperski, that it is not possible to define or speak about an Actor in isolation and only a system of axioms and logical proofs comes close to capture its full meaning. Technological sequential-parallel “implementations” and “representations” will at most address some aspects of the Actor Model.
The demands for “material proof” of the Actor Model arise from a fiction, the fiction that it is possible to isolate an Actor or some Actors and show their “connections,” “data flows” and “mailboxes” and “execution threads.” As Hewitt writes in the previously mentioned paper (Actor Model of Computation): “The following are not required by an Actor: a thread, a mailbox, a message queue, its own operating system process, etc.” –but many commentators don’t seem to attach any relevance to those words. (See: http://arxiv.org/abs/1008.1459 – page 3)
Contrary to Hewitt’s clear argumentation, the automatic resistance that he finds in some quarters of the computing engineering world reveals a search for reassurance and conformity. I see only examples of convergent thinking, where most participants only “understand” what they already know and automatically reject anything that does not confirm their techno-centric worldviews.
Hewitt summarised this situation (perhaps without intention) when he wrote recently:
“Existentially closed minds. A mathematical proof is a very strong argument that has significance in itself.” (C. Hewitt, answering a post in the LtU website on February 23rd, 2014. http://lambda-the-ultimate.org/node/4888#comment-78739)
And this is a really an issue of existential “closure” as those who lightly dismiss the Actor Model are not looking for a logical proof and are only seeking psychological comfort and technocratic consensus.
Simultaneously, we need to understand (perhaps in contradiction with some of Hewitt’s expectations) that the current technology (the nature of current microprocessor computing) creates and maintains a context that is not favourable for a theoretical breakthrough. It has not been favourable to the Actor Model in the past and it will be even less so in the future if I am not wrong. This is because the technological “en-framing” has resulted in a tangle of requirements, both of parallelism and concurrency, for any theory of computation. Computer programming is, after all, an activity focused on the control of existing machines with a dominant type of architecture (the microprocessor) and socio-technical organisations that depend financially and politically on the “success” of this type of technology. So the essence of the machine predetermines the possibility space of what a theory of computation “can be.” It imposes the limits of acceptability and disallows anything that may run against the “en-framing.”
As it is now, I repeat, current technology presupposes and demands a mixture of parallelism and concurrency. Moreover, in this mixture, the primary requirements are for parallelism (i.e. arrays of identical processors) and concurrency appears as a secondary set of requirements and only as a result of the “problems” caused by conflicting resource access and use. Hence, the entire discussion around parallelism and concurrency is not only sometimes confused as to the nature of concurrency, but is also slanted or loaded towards a preference for sequential-parallel computation. The determinant factors derive from what the industry “can do now” and only marginal attention is given to the nature of concurrent computation.
Again and again the engineer’s question is: what *can* be computed, so the engineering response is: computation is what can be computed. Whereas Hewitt and his collaborators have been addressing the question *what* computation is. The philosophical perspectives are not merely “contradictory” or “opposed” because the first one is lost in the Being of “beings,” i.e. in the maze of the representational, while the second is pointing to the ground of “Being,” so the engineering perspective can never understand the Actor Model, but the Actor Model can explain the engineering perspective with ease. (For the philosophical implications of this, see: M.Heidegger, “Introduction to Metaphysics,” translated by G. Fried and R. Polt, Yale University Press, 2000.)
Concurrency, as Hewitt sees it, is not only universal but also more fundamental than parallelism and is the primary ground of computation. The Actor Model has no sense outside of this understanding. This ground, nevertheless, cannot be perceived directly, as we (as a civilisation) can only think about concurrency through the notion of parallelism. (This is similar to the fact that we can understand absolute discontinuity –for example in the physical sense and in daily experience—but we can describe it only within a continuous numerical system (the real numbers).
Because of the immediate “en-framing” rooted in the current computing technology, the practical and symbolic power of the “machine” at the level of our individual experience, nothing can convince the engineers of the need, meaning or relevance of the Actor Model. He or she cannot accept or believe that reality is only interaction. For in any interaction the engineer will see “objects” and will seek to “define” and “represent” connections and “flows” between “objects” an hence will understand any “actor” within this metaphysical framework.
That still leaves a space “outside” of the machine (between machines) where “concurrency” is clearly relevant (as contention for resources, asynchronous behaviour, etc.) Nevertheless, even this is not enough to demonstrate the relevance of the Actor Model, because the “objective” engineer will latch to a solution from the mechanistic perspective: no “generality” is necessary from this point of view, and only performance questions arise with resource contention and process concurrency.
The problem is that parallelism will never require Actors or its corresponding logic. The Actor Model may be directly implementable in hardware, but it will have to be “hardware” that currently does not exist. Concurrency at the machine level has to prioritise parallelism for the simple reason that the existing machines are sequential-parallel and will be even more so in the future.
Outside of the level of the “isolated” machine, concurrency is more visible, but the engineering practice will always address it an optimisation problem, looking for solutions in terms of timing, redundancy, failover and resiliency (which is precisely what the great majority of Software Engineers working on “concurrency” are doing now). This is –for example–the approach taken by the Erlang engineering community.
Despite the claims of having inaugurated a new Concurrency Oriented Programming paradigm, the Erlang designers *do not mean* concurrency, or better said, they *define* Erlang concurrency as those mechanisms that allow their systems to fail safely and eventually recover by means of clever process isolation. Erlang is not a solution for concurrent computing but an embodiment of the “let it crash principle.” (This is particularly clear in Joe Armstrong’s thesis: “Making reliable distributed systems in the presence of software errors,” 2003 – http://www.sics.se/~joe/ )
From my research I see that this approach has a very high price in terms of Security, as all Security-related principles and requirements are shunted away and relegated to the environment, the operating system or other programming tools. The main effect of the “let it crash principle” is that *other* systems (and not Erlang-OTP) have to pick up the pieces and safeguard any Security requirements, if these exist.
As a consequence of the persistent misunderstandings that exist about the Actor Model, Erlang is erroneously presented (although not by original designers of Erlang themselves!) as an implementation of Hewitt’s Actors, even when it has nothing to do with it. In fact, a proper implementation of the Actor Model would be secure from the bottom up and would exhibit fundamental properties which Erlang does not have (for example capability-based security at “process” and transaction level).
The whole confusion gyrating around the Erlang language and platform arises from the misunderstandings and errors that can be seen in the history of the Actor Model. These arise from a techno-centric culture which effectively negates the nature of concurrency and –as the positivists of the previous century– keeps telling to itself: “only what I see exists; only sensory perception is the basis of truth.” Translated: “Concurrency is only what I can model as concurrent, concurrency is only what I can simulate on my sequential-parallel machines. The world is not universally concurrent because I cannot model it.”
We are in a condition of Being where we can (with great effort) think of concurrency but cannot “implement” it within a technological context which by its own nature prohibits a theory of Actor concurrency; and marginally lets it appear only as situations of resource contention. We live in a condition where we are attached to “beings” and have lost access to Being itself.