Agent Oriented Design in the real world? [closed]

Question

We've been learning about Agent-Oriented-Programming in my software development class, and my professor is a huge proponent of it, having worked with it his whole life.

My question is about the true advantages/disadvantages of using Agents from both a design and implementation perspective. From my professor's point of view, Agents can recreate very complex operations much more easily than through normal OOP methods. But it seems to me that Agents are equally cumbersome to program in complex environments. They are subject to various concurrency, timing, and data integrity issues. From a coder's perspective, Agent code is rather convoluted and is much harder to understand than normal OOP code.

Can someone give me an idea of how software Agents are viewed in real development and what the advantages/disadvantages are outside of an academic exercise?

Answer 1

The use of the term "agents" in AI (which is most likely what you're referring to, it's the most common academic reference) is really a synonym for "software program that acts on a user's behalf". An agent is seen is more attractive because it's a somewhat personified term, being a proxy for a user; also, it tends to be associated with higher order functionality (planning for agents, learning for agents, autonomous agents, etc.). More about the origin of the term on Wikipedia:

http://en.wikipedia.org/wiki/Software_agent

Given that, the term "agent" is more about the purpose and type of software, not how it is programmed. OOP has more to do with how it is technically designed/implemented.

So there is nothing wrong with designing your agents using OOP principles. The two subjects are not mutually exclusive.

Also, keep in mind (as some of the comments above allude to, and I agree with): use of "agents" in academia is more romanticized term; most software acts on some user(s) behalf, and so there is agent functionality in many things. It's just software at the end of the day, and if you removed the term "agent" from our collective lexicon, you wouldn't be punishing the capability of pure software design/implementation any. You will see elements of this same debate in forums specifically about agent oriented programming, e.g.:

http://ootips.org/agent-orientation.html

Answer 2

What I'm missing in all the answers and what I thought are the most important differences between agent/actor oriented programming and "normal" OOP is that:

• AOP is a higher layer or "level" on top of OOP (often implemented using OOP).

• AOP is all about making concurrent (multi threaded) programming easier, have a well defined standard way of doing it (per language or framework) and therefor making it more clearly structured. The concurrency functionality is implemented in the AOP framework or language, whereas multi threading in OOP is left up to the developer and can be implemented in any way he/she likes (one of which could be AOP :P).

Examples of languages that have some implementation to allow for AOP out of the box: newer versions of NI Labview and Erlang. Wiki has more examples.

Intuitively I would guess that in general: the more functionality you add to software, the more you would benefit from using AOP. If you don't use AOP (or some other multi-threading framework), you will probably run into all of the problems that AOP already solved for you, such as: dead-locks, racing conditions, inefficient communication between threads (event queues, message queues, data queues, etc).

A good example of an (accidental) actor oriented architecture: the internet. Because it consists of "agents" (nodes/servers/clients) that function concurrently and can tolerate failure of other servers and communication channels.