Why has the actor model not succeeded?   Paul Mackay pjm2@doc.ic.ac.uk   Be not afraid of greatness.  Some are born great, some achieve greatness, and some have greatness thrust upon ‘em.   [Twelfth Night, II.v]   Introduction   To this day, the actor model has not yet achieved greatness or wide recognition and use, and it is unknown whether it may ever have greatness thrust upon it. What are the reasons for its minor role to this day? Indeed, as yet there has not been a complete implementation of the theoretical actor model. Several useable actor based languages have been written, but they tend to include features which extend the functionality to some extent.   The actor model or paradigm was created by Carl Hewitt in the early 1970’s. During this time there was a veritable explosion of programming language development, as the power and capability of computers increased. It became apparent as the desire for larger and more complex software increased that imperative languages broke down as the size grew beyond a certain point.   The Object-Orientated Model   The development of the object model, and object orientated programming began with Simula, but the first true OO language was Smalltalk in its third incarnation in 1976. Later languages such as C++ were developed and became extremely popular, and are used for a wide variety of applications today. One of the factors which drove the development of the new paradigms is artificial intelligence (AI) research. The actor model was created for use in AI and in parallel or distributed systems, for it was found that AI required heavy computation. The model lent itself to open systems, which could be continually evolving. One of the reasons for the object model’s success is that it dealt with the structure of programs in a fundamentally different way. The problem was broken down using abstraction into the objects which it contained, their properties and the relationships between them. Encapsulation hid the implementation of these properties from the user of the objects, and the modularity of this structure made it easier to understand. Hierarchy (or inheritance, to a more specialist degree) allowed the reuse of common code among particular objects having the same general characteristics. Other features such as typing, concurrency and persistence were developed which aided the production of more robust and versatile code.   These new ways of examining the problem provided programmers with the ability to break down a complex problem into simpler concepts. This meant much larger software could be written, to take advantage of the new hardware technology being developed. As greater demands were made by new applications of software, parallel systems were developed for the processing power they offered. Parallel systems were expensive, and it was found that distributed systems, where two or more smaller desktop computers were linked together in order to share processing power and data, were more cost effective.   Distributed Systems   The abstract model of a distributed system requires comprehensive, secure communications facilities for the system to operate efficiently. Message passing is used because it can provide communication with remote processors, wherever they may be. Due to its distributed nature, the time taken for transmission of messages can vary, which means that synchronous communication is very inefficient in this context. In this respect the actor model seems ideally suited for use with distributed systems. It communicates exclusively using message passing, and is completely asynchronous. So why has the actor model been unsuccessful in this area for which it was designed?   When the actor model was first proposed, the development of distributed networks was in its infancy. The conceptual model of actors is easy to understand as it allows state to be directly expressed.[1] Also the only side effects of an actor are to send communications and to set a new behaviour. The simplicity of this model suggests that it would make programming for a distributed system simpler, but there proved to be difficulties associated with its implementation.   Problems of the Actor Model   The actor model has no direct notion of inheritance or hierarchy, which means it is time consuming and confusing to program actors with trends of common behaviour. Actors allow abstraction of the concepts, but in almost all non-trivial programs there will be many kinds of abstraction. Actors encompass the ideas of modularity and encapsulation though, because an actor is self contained[2] and can be considered atomic. There are also issues more fundamental to the architecture which prove hard to realise. One of the key features of actors, their ability to create other actors as part of their behaviour, has the potential to dramatically change the state of the system at any particular time. The decisions of where to store and execute newly created actors is important to overall performance, and will require records to be kept of what is executing and where. If the system is very distributed, (e.g. the Internet) then the communications involved between different locations must also be noted, as they will affect performance drastically between remote locations.   Another problem is behaviour replacement. The behaviour is dynamic, and very difficult to perform using a static language (e.g. C). Static analysis cannot support reflection, or reconfiguration of the runtime system. The fact that the behaviour can be altered also makes optimisation of the program very difficult. The notion of weak fairness in guaranteeing delivery of messages requires unbounded mailboxes. This implies some form of infinite stack or pointer structure, but it cannot be assumed that this is available in all architectures. The memory requirements of object-orientated programs can usually be determined before runtime.   The idea of asynchronous message passing  may cause problems with certain programs or algorithms. For example, manipulation of a stack-like structure using asynchronous message passing could be problematic if the messages do not arrive in the correct order. When an actor requires a reply message from another actor, it is known as an insensitive actor, and will not process any further messages in its mail queue until it receives that reply. While being conceptually elegant, this is hard to implement efficiently, because the actor’s one message queue must handle both the reply message and new messages from elsewhere. Object-orientated programs also rely on message passing to a degree, but with the use of strong typing and static resolving, the number of dynamic method invocations requiring a message can be reduced substantially. This is much more difficult using actors. The actor model also uses many more actors than the object model uses objects for equivalent functionality, because in the actor model even an integer is represented as an actor.   Conclusion   The problems outlined above are some of the inherent difficulties associated with the actor model. When the model was first proposed, the knowledge of distributed and parallel systems was not advanced enough to be able to adapt the conceptual model to an efficient implementation of an actor language. The actual languages based on actors were adapted to make their organisation easier. In recent years research has led to more efficient methods for implementing the model, and the other driving force is that the nature and knowledge of networks and systems today has greatly expanded. The growth of the Internet, the truly global distributed network, must use asynchronous message passing, due to the very remote locations of processors and the time delays inherent in transmission. Mobile computing as a technology and a way of working has also grown from nothing during the 80’s and 90’s. More recent studies have shown that the actor model at its current stage of development can now be made efficient to the necessary level for the today’s requirements.      References:   [1] G.Agha, C. Houck and R. Panwar. Distributed Execution of Actor Programs. University of Illinois.   [2] G. Agha. An Overview of Actor Languages. MIT, Cambridge, Mass. June 1986