Any computer science academic (or readers of /r/programming) hear it loud and clear: Parallel and distributed computing is a hot topic. Modern programming languages like Java, Erlang and minions e.g. Akka are raising the profile of foremost challenges of parallel computing to a wider audience. Scalability, asynchronicity, fault tolerance and so on. However, people have been thinking about the implications and challenges of well behaved distributed computing e.g. (Khan, 1974), long before petascale or even the multicore chip. Parallel computing was for a long time a mere academic curiosity. In the naughties (00’s), non scalable codes became an economic concern for industry (Ambrust, 2010).
What does agent-oriented programming have to do with distributed parallel computing? Unfortunately, agent-oriented programming is sometimes confused with concurrent or parallel programming. First though, a definition in a seminal paper on agent-oriented programming (Y Shoham, 1993):
The mental state of agents is described formally in an extension of standard epistemic logics: beside temporalizing the knowledge and belief operators, agent-oriented programming introduces operators for obligation, decision, and capability.
Researchers sometimes use the term agent-oriented programming to describe cognitive, often proactive and communicative independent units. An agent may be described as any program that acts on behalf of a human user (NM Kamik, 1998). They may hold beliefs, and have desires and intentions in formalised BDI systems (A Rao, 1995). The BDI model is a well-known software model for programming intelligent rational agents. Agents may cooperate in reactive or decision-theoretic planning decisions.
Now for some implementations of agent languages and runtime systems. Many agent-oriented programming languages are based on the Prolog-like logical goal reduction approach where rules are used to reduce, in depth-first way, a selected goal (R Bordini, 2009).
It all sounds very promising. Time for a reality check. A widely cited roadmap for agent programming offers a word of warning against intellectual pomposity in the agent community:
Several observers feel that certain aspects of agents are being dangerously over-hyped, and that unless this stops soon, agents will suffer a similar backlash to that experienced by the Artificial Intelligence (AI) community in the 1980s (N Jennings, 1998).
I’m sure Jennings had his reasons to promote this warning to the Introduction Section on page 1 of his roadmap. But I recognise the hype within my own interests in distributed parallel computing. Indeed, there are overlaps between agent frameworks and concurrent & distributed parallel programming. Take Jade (F Bellifemine, 1999) as an example. It is a Java based software framework widely known in the agent community, perhaps in part due to the popularity of the host language. It is used to develop agent applications in compliance with the FIPA specifications for interoperable intelligent multi-agent systems. A widely held view is that agent programming has fallen not far from its object oriented parent:
|Object Oriented||Agent Orient|
|State parameters||Unconstrained||Beliefs, capabilities, choices…|
|Process of computation||Message passing & response methods||Message passing & response methods|
|Message types||Unconstrained||Inform, request, offer, decline…|
|Constraints of methods||None||Honesty, consistency…|
So, correlations between object oriented and agent oriented programming then. What about other models? Another candidate is the actor model, popularised by the successful Erlang language. An observation often overlooked is the commonality between actors and agents. They both communicate with message passing, they do not share state (or “beliefs” if you like), and are scheduled independently. People who are aware of both models are often keen to seek the clarifications.
What can established parallel programming models and well-engineered distributed systems offer the agent community? A great deal, in fact. Three popular programming models for parallelism are the actor model in Erlang (J Armstrong, 1996), the continuation-passing style in Cilk (R Blumofe, 1996) and parallel message passing with MPI (W Gropp, 1999). Moreover, hot research areas include load balancing parallel machines e.g. (A Zain, 2005), and fault tolerance programming abstractions such as Erlang OTP. Distributed runtime systems can also provide a great deal of insight to the agent-community.
Take the Erlang virtual machine as a case study. It can be deployed at large scale, on clusters or wide are networks, and the Erlang runtime system supports the high level programming features e.g. supervision behaviours for fault tolerance. That is, actors can be started (not necessarily at the start of computation), they can live short or long lives, they communicate with other actors with message passing, they can be proactive or reactive, and can be automatically restarted if they fail. There is without question a big overlap between the Java based Jade framework, and the Erlang programming language and virtual machine. A detailed comparison of the two would be very worthwhile. My concern is that by simply replacing the term actors with agents in this description of Erlang is enough to promote its prestige in some academic quarters.
An analogy would be to view Jade as Erlang + formalised communication. Indeed, Jade agents use Agent Communication Language (ACL) (FIPA ACL, 2002) to cooperate. A fascinating project idea would be to apply a FIPA-ACL layer on top of message passing in Erlang or even CloudHaskell (Epstein, 2011). One FIPA implementation in Erlang is eXAT (A Stefano, 2009). The library provides the programmer with the possibility of developing agents with behaviours, intelligence, and collaboration using ACL. I would especially encourage the reader to inspect the micro-benchmark Jade vs eXAT language comparison in Figure 3 of (A Stefano, 2009) - spoiler: functional programming is shorter and much cleaner.
There are times then, when the agent community publish papers about programming models and computational systems are are not exclusive to agents. I have already listed some distributed programming languages and virtual machines. I describe only the tip of the iceberg. I occasionally hear people describe agent-oriented programming as a good way to write modular code. That is, agents should be small and simple, the intelligence emerges from their cooperative goal seeking. I ask: “who doesn’t write modular code!”. Every good developer writes composable software. The advantages of treating a software system as modular rather than monolithic are well understood. Modularity allows for the problem to be decomposed into simpler components which are easier to build, maintain and understand.
Take an example of Amazon’s online store. Here I speculate on the engineering that might be involved. There will be hundreds, if not thousands of simple web services, that take a simple input (e.g. ISBN number), and return a simple output, maybe a record for a book. These web services are likely written in an object oriented language. You might describe the web services as having a goal: wait for an ISBN number, then search through multiple data sources for a book, and return what it has found. Is this an AI inspired distributed multi-agent system with seemingly magical powers of reasoning? No. It is a well designed IT infrastructure developed by clever engineers in industry, who know how to write robust software with corresponding testsuites for production environments.
Over its 40-year history, AI has been subject to many and varied criticisms. Perhaps the most persistent and troubling of these is that AI has simply failed to deliver on its promises … At least part of the answer is also that many AI researchers either ignore or else gloss over the pragmatic concerns of software development … Software engineering is generally regarded as neither a contributor nor a concern (M Wooldridge, 1997).
It is not enough to say that a domain specific language is agent oriented because it encourages modular code. It is not enough to say that it is agent oriented because those units have self-beliefs, live long lives and cooperatively pass messages. It is not an agent framework just because you can deploy it on a cluster or wide area network. A framework is worthy of the “agent” label if, for example, its runtime system performs reduction on user code, and orders the execution of units using reasoning techniques (3APL, Jason, DTGolog…).
The other option open to the community is to knowingly use the “agent” tag more liberally. And that is fine. But we must then all accept its ambiguous nature, and carefully scrutinise the reasoning powers of agent systems on a case by case basis.
Ambiguous tests can be interpreted in two different ways: as an assertion that is true but relatively banal, or as one that is radical but manifestly false. They offer a great advantage in intellectual battles: the radical interpretation can serve to attract relatively inexperienced listeners or readers; and if the absurdity of this version is exposed, the author can always defend himself by claiming to be have misunderstood, and retreat to the innocuous interpretation. (A Sokal, 1997).