This document collects some notes and points emerged during discussion in AGERE! and SPLASH among the participants.

Not only about performances but how to think, design, and conceptual modelling


Many papers & talks in workshops and in SPLASH (OOPSLA/OnWard!) were directly or indirectly about concurrency and how to program apps the big tide/hype on multi-core and many-core programming, including a SPLASH panel (*).  However, all such contributions  were mostly about performances, and comments, ideas, proposals about mechanisms, strategies, algorithms to make the execution of OO and functional programs more efficient - reducing locks & all the techniques that are quite well known in the context of parallel programming.  

Conversely, a main perspective at the core of AGERE! - and nicely and clearly  put forward also by Kresten in his tech talk (**) - is about conceptual modelling, or the power of actors and agents abstractions to ease the programming and design of software systems, how to think to problems and what kind of concepts can be used to conceive solutions.

In this perspective, the “free lunch is over” call - as called by Sutter & Larus (***) - is not only related to find suitable ad hoc algorithms and mechanisms to exploit the computational power given by the multi-core, many-core & parallel HW - this actually has been widely explored and it is still being explored by the research community working on parallel programming and high-performance computing. But to define a new level of abstraction - probably on top or as an evolution of the OO one - that allow to naturally exploit concurrency, decentralization of control, distribution as tools to think about and develop software - putting at the center of the stage some aspects and features such as interaction, reactivity, autonomy, encapsulation & modularity of control, task & goal oriented behaviour, asynchronous message passing, asynchronous event handling, and so on.

(*) Among the others, a SPLASH panel was specifically about this (“Multicore, Manycore, and Cloud Computing: Is a new programming language paradigm required?” Tucker Taft, Joshua Bloch, David Ungar, Guy Steele, Sebastian Burckhardt,  Benedict Gaster,  Russ Cox,  Hassan Chafi,  Robert Bocchino) and also the Ungar’s invited (“Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future”).

(**) Kresten Krab Thorup, “Erlang, the Road-Movie”, SPLASH 2011 tech talk,

(***) Software and the Concurrency Revolution, ACM Queue, 2005

On the need of  stronger development tools (languages, platforms & related ecosystem)

Given the perspective above, the role of proper programming languages, frameworks and tools become fundamental in order to suitably support programming and design activity, that would directly allow for easily and directly working with such concepts & features, reducing as much as possible the gap between the conceptual layer and the development tools.

Generally speaking current actor-based languages and, even more, agent-based languages provide a weak support to make actor-based programming and agent-oriented programming easy,  robust and agile compared to the support that OO / functional languages nowadays provide for OOP and functional programming.

Some presentations in AGERE! were in that direction, introducing features that finally allow to ease programming / testing / debugging. Examples are:

It is worth remarking that features can be inspired by existing counter-part in other paradigms (such as the notion of contract or type), yet they are here re-framed and possibly empowered by exploiting the level of abstraction (and related specific peculiarities) provided by actors and agents.

It is not only about message passing: Behavioural & Control- Oriented Programmg

Asynchronous message passing are a core fundamental feature of actors and agents, however actor and, above all, agent thinking and computing it is not only about message passing. Among the features that are essential - that are kinds of precondition for asynchronous message passing - is decentralization of control, that leads to find proper abstraction for decentralized control encapsulation, modularization, composition. So applying programming and software design principles to the construction of decentralized control and interactive software systems.

How to structure, modularize, organize the overall autonomous behaviour of possibly complex actors, agents?  Is it useful to introduce further explicit abstractions to this purpose? How to program behaviours that accommodate reactivity with pro-activity, i.e. an even-driven/reactive behaviour with a pure active/task-driven one?

The notion of Behavioral-Programming and Control-Oriented Programming was raised in particular in the paper of Behavioral Programming, Decentralized Control, and Multiple Time Scales (David Harel, Assaf Marron, Guy Wiener and Gera Weiss - Weizmann Institute of Science, Ben Gurion University), as well as in the paper about the simpAL agent language where some specific concepts - e.g., plans - are introduced to structure the reactive and proactive behaviour of the individual agent.

Behavioural programming was discussed also in the OnWard! paperCoding at the Speed of Touch" (Sean McDirmid, Microsoft Research Asia) and can be clearly recognised as the main conceptual brick (along with asynchronous message passing) in languages such a Scratch.

"Actors everywhere" but often with weak semantics


Today, the actor model is getting a momentum in many programming languages as an explicit or implicit reference model and direction to take for doing concurrent programming away from threads and related low-level synchronization mechanisms. Examples range from general purpose frameworks like Scala Actors, well-known and solid concurrent/distributed programming languages and systems like Erlang (with the notion of process), to new programming languages like DART (with the notion of isolates), cloud-oriented frameworks like Orleans and Axum on the .NET framework.

However it can be argued that most of the approaches implements the basic idea not enforcing some main properties that characterize the actor semantics, finally affecting the shape and properties of programs.  This point has been raised during the workshop discussion. A useful reference for these remarks is the paper Actor frameworks for the JVM platform: a comparative analysis (Karmani, Shall, Agha) presented at PPPJ '09 Proceedings of the 7th International Conference on Principles and Practice of Programming in Java.

Be back on the “road not taken”

If we go back to the origin of objects and OOP, we can recognize what Mark Miller defined during AGERE! discussion “the road not taken”, that is all those principles and ideas that nowadays we have in actors and OOCP languages - for instance - but no more in objects as implemented by mainstream OOP languages. Given the widespread diffusion of concurrent , distributed, mobile programming, we can see now the opportunity to be back on the road not taken, given the fact that the dominant notion of object cannot effectively capture at the proper level of abstraction such worlds. A way to be back is “making tunnels”, so injecting in OO traditional languages features that clearly drive back to the road not taken.  

Writing down practices & patterns

During the discussion, a point on the importance to have practical textbook describing programming idioms, patterns based on actor/agent paradigm, and more generally guidelines to apply actor/agent thinking to solve problem, model & design systems, program applications based has been raised. This view is proposed by Mario Henrique Cruz Torres presenting the paper No More Design Patterns for Multi-Agent Systems (Mario Henrique Cruz Torres, Tony Van Beers, Tom Holvoet).

On the differences between actors and agents as programming abstractions  

The workshop has been an opportunity also to start discussing and comparing actor and agent models, trying to identifying distinguishing features and finally the path that allow to go from one level to the other level and back.  These points were discussed in particular in the papers

A Feature Model of Actor, Agent, and Object Programming Languages (Howell Jordan, Goetz Botterweck, Marc-Philippe Huget and Rem Collier) and Designing a General-Purpose Programming Language based on Agent-Oriented Abstractions: The simpAL Project (Alessandro Ricci, Andrea Santi).

One of the top features of OO is related to conceptual modelling, how OO is effective in modelling real world and domain problems by means of the ideas of objects and message passing.  This feature is even more remarked when going from sequential to concurrent models, so in OOCP (Object-Oriented Concurrent Programming) à la ABCL and in Actor and actor-like approaches, including process-based like Erlang. This is because obviously we live in higly concurrent, distributed and decentralized world - and it is natural to model every kind of interaction as message passing between actors/autonomous objects/processes - actually, as often Alan Kay remarks - message passing is the essential concept of Object-oriented programming or Object-based programming, in its original and purest acceptation, in spite of the sequential or concurrent model.

Said this, agents allow for improving even more this conceptual modelling, in two ways among the others.  

  First, by capturing a main aspect of interactions which is not a first class idea in the actor/OOCP worlds and which is - instead - pervasive in real world. That is: observation, perception, and action.  Agents - besides interacting directly with other agents by speech acts and asynch message passing - are first of all situated in some Environment (first class concept) which they perceive and act upon.  Agents don't talk with the environment, they perceive (observe) events/state of the environment and they do actions to change it. This is clearly strongly analogous to what happen to people and living entities in the concurrent world. People talks to people, but also continuously observe and use their environments, composed by objects, tools, instruments, non autonomous entities and then also other people. Observation (perception) is a fundamental kind of interaction distinguishing living (autonomous) entities vs. not living one, their continuous coupling with the environment when they are situated. And it is something conceptually different from message passing: observing the display of a coffee machine is not like sending a message to the machine to ask about how much money are inside and receiving a message back.  The observed thing is not aware of the observer(s), and the perception by the observer is not because of an intentional message sent by the observed to the observers.    Indeed, the observer pattern is pervasive also in programming, unfortunately resulting in inversion of control in traditional sequential OO languages which is problematic as soon as we are in concurrent programs. Obviously can be implemented under the hood by message passing - which is powerful enough to model any kind of interaction model - but conceptually it is a different thing. So, a main distinguishing feature of Agent abstraction in programming is making Environment - and the perceptions/events and actions - first-class concepts, besides message passing.  So agents talk to agents, but perceive and act upon the Environment. Realizing then the observer pattern, without inversion of control and fully integrated with a task-oriented behaviour.

Second, if actors does something because they receive a message, agents do something because they have some goal to achieve or tasks to accomplish.  Tasks can be assigned by message passing indeed, but not every message exchange is for assigning tasks. Furthermore, an agent can have self-allocated tasks or predefined tasks defined at compile time, or even triggered observations of the environment, so without necessarily involving message passing.

Following this perspective, agent oriented programming  introduces a further higher-level abstraction layers on top actors’ one that make it possible to represent and manipulate as first-class design and computational concepts tasks, goals, plans to achieve goals and to asynchronously react to events, and so on. So agents conceptual (and programming) space  can be framed as an extension of actors’ one, enriching it with native concepts that are meant to  ease the development of (systems of) complex autonomous entities - possibly exhibiting complex interacting and computational behaviour, pro-actively doing actions to do some task and reactively managing events perceived asynchronously from the environment where they situated, including other agents.