Encyclopedia of Complexity and Systems Science

Living Edition
| Editors: Robert A. Meyers

Agent-Based Modeling and Computer Languages

  • Michael J. NorthEmail author
  • Charles M. Macal
Living reference work entry
DOI: https://doi.org/10.1007/978-3-642-27737-5_8-5


Agent-based mode Agent-based simulation Computer language Complex adaptive systems modeling 

Definition: Agent-Based Modeling and Computer Languages

Agent-based modeling is a bottom-up approach to representing and investigating complex systems. Agent-based models can be implemented either computationally (e.g., through computer simulation) or non-computationally (e.g., with participatory simulation). The close match between the capabilities of available software and the requirements of agent-based modeling make these options a natural choice for many agent-based models. Of course, realizing the potential benefits of this natural match necessitates the use of computer languages to express the designs of agent-based models. A wide range of computer design and programming languages can play this role including both domain-specific and general-purpose languages. The domain-specific languages include business-oriented languages (e.g., spreadsheet programming tools), science and engineering languages (e.g., Mathematica), and dedicated agent-based modeling languages (e.g., NetLogo). The general-purpose languages can be used directly (e.g., Java programming) or within agent-based modeling toolkits (e.g., Repast). The choice that is most appropriate for each modeling project depends on both the requirements of that project and the resources available to implement it.

Agent-Based Modeling

This introduction follows Macal and North (2007). The term agent-based modeling (ABM) refers to the computational modeling of a system as comprised of a number of independent, interacting entities, which are referred to as “agents.” Generally, an agent-based system is made up of agents that interact, adapt, and sustain themselves while interacting with other agents and adapting to a changing environment. The fundamental feature of an agent is its autonomy, the capability of the agent to act independently without the need for direction from external sources. Agent behaviors allow agents to take in information from their environment, which includes their interactions with other agents, process the information and make some decision about their next action, and take the action. Jennings (2000) provides a formal computer science-oriented view of agency emphasizing the essential characteristic of autonomous behavior.

Beyond the essential characteristic of autonomy, there is no universal agreement on the precise definition of the term “agent,” as used in agent-based modeling. Some consider any type of independent component, whether it be a software model or a software model of an extant individual, to be an agent (Bonabeau 2001). An independent component’s behaviors can be modeled as consisting of anything from simple reactive decision rules to multidimensional behavior complexes based on adaptive artificial intelligence (AI) techniques.

Other authors insist that a component’s behavior must be adaptive in order for the entity to be considered an agent. The agent label is reserved for components that can adapt to their environment, by learning from the successes and failures of their interactions with other agents, and change their behaviors in response. Casti (1997) argues that agents should contain both base-level rules for behavior and a higher-level set of “rules to change the rules.” The base-level rules provide responses to the environment while the “rules to change the rules” provide adaptation (Casti 1997).

From a practical modeling standpoint, agent characteristics can be summarized as follows:
  • Agents are identifiable as self-contained individuals. An agent has a set of characteristics and rules governing its behaviors.

  • Agents are autonomous and self-directed. An agent can function independently in its environment and in its interactions with other agents, at least over a limited range of situations that are of interest.

  • An agent is situated, living in an environment with which it interacts along with other agents. Agents have the ability to recognize and distinguish the traits of other agents. Agents also have protocols for interaction with other agents, such as for communication, and the capability to respond to the environment.

  • An agent may be goal directed, having targets to achieve with respect to its behaviors. This allows an agent to compare the outcome of its behavior to its goals. An agent’s goals need not be comprehensive or well defined. For example, an agent does not necessarily have formally stated objectives it is trying to maximize.

  • An agent might have the ability to learn and adapt its behaviors based on its experiences. An agent might have rules that modify its behavior over time. Generally, learning and adaptation at the agent level requires some form of memory to be built into the agent’s behaviors.

Often, in an agent-based model, the population of agents varies over time, as agents are born and die. Another form of adaptation can occur at the agent population level. Agents that are fit are better able to sustain themselves and possibly reproduce as time in the simulation progresses, while agents that have characteristics less suited to their continued survival are excluded from the population.

Another basic assumption of agent-based modeling is that agents have access only to local information. Agents obtain information about the rest of the world only through their interactions with the limited number of agents around them at any one time, and from their interactions with a local patch of the environment in which they are situated.

These aspects of how agent-based modeling treats agents highlight the fact that the full range of agent diversity can be incorporated into an agent-based model. Agents are diverse and heterogeneous as well as dynamic in their attributes and behavioral rules. There is no need to make agents homogeneous through aggregating agents into groups or by identifying the “average” agent as representative of the entire population. Behavioral rules vary in their sophistication, how much information is considered in the agent decisions (i.e., cognitive “load”), the agent’s internal models of the external world including the possible reactions or behaviors of other agents, and the extent of memory of past events the agent retains and uses in its decisions. Agents can also vary by the resources they have managed to accumulate during the simulation, which may be due to some advantage that results from specific attributes. The only limit on the number of agents in an agent-based model is imposed by the computational resources required to run the model.

As a point of clarification, agent-based modeling is also known by other names. ABS (agent-based systems), IBM (individual-based modeling), and MAS (multi-agent systems) are widely used acronyms, but “ABM” will be used throughout this discussion. The term “agent” has connotations other than how it is used in ABM. For example, ABM agents are different from the typical agents found in mobile agent systems. “Mobile agents” are lightweight software proxies that roam the World Wide Web and perform various functions programmed by their owners such as gathering information from Web sites. To this extent, mobile agents are autonomous and share this characteristic with agents in ABM.

Types of Computer Languages

A “computer language” is a method of specifying directives for computers. “Computer programming languages,” or “programming languages,” are an important category of computer languages. A programming language is a computer language that allows any computable activity to be expressed. This entry focuses on computer programming languages rather than the more general computer languages, since virtually all agent-based modeling systems require the power of programming languages. This entry sometimes uses the simpler term “computer languages” when referring to computer programming languages. According to Watson (1989),

Programming languages are used to describe algorithms, that is, sequences of steps that lead to the solution of problems…A programming language can be considered to be a ‘notation’ that can be used to specify algorithms with precision.

Watson (1989) goes on to say that “programming languages can be roughly divided into four groups: imperative languages, functional languages, logic programming languages, and others.” Watson (1989) states that in imperative languages “there is a fundamental underlying dependence on the assignment operation and on variables implemented as computer memory locations, whose contents can be read and altered.” However, “in functional languages (sometimes called applicative languages) the fundamental operation is function application” (Watson 1989). Watson cites LISP as an example. Watson (1989) continues by noting that “in a logic programming language, the programmer needs only to supply the problem specification in some formal form, as it is the responsibility of the language system to infer a method of solution.” Watson cites Prolog as an example.

A useful feature of most functional languages, many logic programming languages, and some imperative languages is higher-order programming. According to Reynolds (1998),

In analogy with mathematical logic, we will say that a programming language is higher-order if procedures or labels can occur as data, i.e., if these entities can be used as arguments to procedures, as results of functions, or as values of assignable variables. A language that is not higher-order will be called first-order.

Watson (1989) offers that “another way of grouping programming languages is to classify them as procedural or declarative languages.” Elaborating, Watson (1989) states that

Procedural languages…are those in which the action of the program is defined by a series of operations defined by the programmer. To solve a problem, the programmer has to specify a series of steps (or statements) which are executed in sequence

On the other hand, Watson (1989) notes that

Programming in a declarative language (or non-procedural language) involves the specification of a set of rules defining the solution to the problem; it is then up to the computer to determine how to reach a solution consistent with the given rules…The language Prolog falls into this category, although it retains some procedural aspects. Another widespread non-procedural system is the spreadsheet program.

Imperative and functional languages are usually procedural, while logic programming languages are generally declarative. This distinction is important since it implies that most imperative and functional languages require users to define how each operation is to be completed, while logic programming languages only require users to define what is to be achieved. However, when faced with multiple possible solutions with different execution speeds and memory requirements, imperative and functional languages offer the potential for users to explicitly choose more efficient implementations over less efficient ones. Logic programming languages generally need to infer which solution is best from the problem description and may or may not choose the most efficient implementation. Naturally, this potential strength of imperative and functional languages may also be cast as a weakness. With imperative and functional language, users need to correctly choose a good implementation among any competing candidates that may be available.

Similarly to Watson (1989), Van Roy and Haridi (2004) define several common computational models, namely, those that are object oriented, those that are logic based, and those that are functional. Object-oriented languages are procedural languages that bind procedures (i.e., “encapsulated methods”) to their corresponding data (i.e., “fields”) in nested hierarchies (i.e., “inheritance” graphs) such that the resulting “classes” can be instantiated to produce executable instances (i.e., “objects”) that respond to multiple related messages (i.e., “polymorphism”). Logic-based languages correspond to Watson’s (1989) logic programming languages. Similarly, Van Roy and Haridi’s (2004) functional languages correspond to those of Watson (1989).

Two additional types of languages can be added to Van Roy and Haridi’s (2004) list of three. These are unstructured and structured languages (Dijkstra 1968). Both unstructured and structured languages are procedural languages.

Unstructured languages are languages that rely on step-by-step solutions such that the solutions can contain arbitrary jumps between steps (Dijkstra 1968). BASIC, COBOL, Fortran, and C are examples of unstructured languages. The arbitrary jumps are often implemented using “goto” statements. Unstructured languages were famously criticized by Edsger Dijkstra in his classic paper “Go To Statement Considered Harmful” (1968). This and related criticism lead to the introduction of structured languages.

Structured languages are languages that divide programs into separate modules, each of which has one controlled entry point, a limited number of exit points, and no internal jumps (Dijkstra 1968). Following Stevens et al. (1974) “the term module is used to refer to a set of one or more contiguous program statements having a name by which other parts of the system can invoke it and preferably having its own distinct set of variable names.” Structured language modules, often called procedures, are generally intended to be small. As such, large numbers of them are usually required to solve complex problems. Standard Pascal is an example of structured, but not object-oriented, language. As stated earlier, C is technically an unstructured language (i.e., it allows jumps within procedures and “long jumps” between procedures), but it is used so often in a structured way that many people think of it as a structured language.

The quality of modularization in structured language code is often considered to be a function of coupling and cohesion (Stevens et al. 1974). Coupling is the tie between modules such that the proper functioning of one module depends on the functioning of another module. Cohesion refers to the ties within a module such that proper functioning of one line of code in a module depends on the functioning of another one line of code in the same module. The goal for modules is maximizing cohesion while minimizing coupling.

Object-oriented languages are a subset of structured languages. Object-oriented methods and classes are structured programming modules that have special features for binding data, inheritance, and polymorphism. The previously introduced concepts of coupling and cohesion apply to classes, objects, methods, and fields the same way that they apply to generic structured language modules. Objective-C, C++, C#, and Java are all examples of object-oriented languages. As with C, the languages Objective-C, C++, and C# offer goto statements but they have object-oriented features and are generally used in a structured way. Java is an interesting case in that the word “goto” is reserved as a keyword in the language specification, but it is not intended to be implemented.

It is possible to develop agent-based models using any of the programming languages discussed above, namely, unstructured languages, structured languages, object-oriented languages, logic-based languages, and functional languages. Specific examples are provided later in this entry. However, certain features of programming languages are particularly well suited for supporting the requirements of agent-based modeling and simulation.

Requirements of Computer Languages for Agent-Based Modeling

The requirements of computer languages for agent-based modeling and simulation include the following:
  • There is a need to create well-defined modules that correspond to agents. These modules should bind together agent state data and agent behaviors into integrated independently addressable constructs. Ideally these modules will be flexible enough to change structure over time and to optionally allow fuzzy boundaries to implement models that go beyond methodological individualism (Heath 2005).

  • There is a need to create well-defined containers that correspond to agent environments. Ideally these containers will be recursively nestable or will otherwise support sophisticated definitions of containment.

  • There is a need to create well-defined spatial relationships within agent environments. These relationships should include notions of abstract space (e.g., lattices), physical space (e.g., maps), and connectedness (e.g., networks).

  • There is a need to easily set up model configurations such as the number of agents, the relationships between agents, the environmental details, and the results to be collected.

  • There is a need to conveniently collect and analyze model results.

Each of the kinds of programming languages, namely, unstructured languages, structured languages, object-oriented languages, logic-based languages, and functional languages, can address these requirements.

Unstructured languages generally support procedure definitions which can be used to implement agent behaviors. They also sometimes support the collection of diverse data into independently addressable constructs in the form of data structures often called “records.” However, they generally lack support for binding procedures to individual data items or records of data items. This lack of support for creating integrated constructs also typically limits the language-level support for agent containers. Native support for implementing spatial environments is similarly limited by the inability to directly bind procedures to data.

As discussed in the previous section, unstructured languages offer statements to implement execution jumps. The use of jumps within and between procedures tends to reduce module cohesion and increase module coupling compared to structured code. The result is reduced code maintainability and extensibility compared to structured solutions. This is a substantial disadvantage of unstructured languages.

In contrast, many have argued that, at least theoretically, unstructured languages can achieve the highest execution speed and lowest memory usage of the language options since nearly everything is left to the application programmers. In practice, programmers implementing agent-based models in unstructured languages usually need to write their own tools to form agents by correlating data with the corresponding procedures. Ironically, these tools are often similar in design, implementation, and performance to some of the structured and object-oriented features discussed later.

Unstructured languages generally do not provide special support for application data configuration, program output collection, or program results analysis. As such, these tasks usually need to be manually implemented by model developers.

In terms of agent-based modeling, structured languages are similar to unstructured languages in that they do not provide tools to directly integrate data and procedures into independently addressable constructs. Therefore, structured language support for agents, agent environments, and agent spatial relationships is similar to that provided by unstructured languages. However, the lack of jump statements in structured languages tends to increase program maintainability and extensibility compared to unstructured languages. This generally gives structured languages a substantial advantage over unstructured languages for implementing agent-based models.

Object-oriented languages build on the maintainability and extensibility advantages of structured languages by adding the ability to bind data to procedures. This binding in the form of classes provides a natural way to implement agents. In fact, object-oriented languages have their roots in Ole-Johan Dahl and Kristen Nygaard’s Simula simulation language (Dahl and Nygaard 1966, 2001; Van Roy and Haridi 2004)! According to Dahl and Nygaard (1966),

SIMULA (SIMULation LAnguage) is a language designed to facilitate formal description of the layout and rules of operation of systems with discrete events (changes of state). The language is a true extension of ALGOL 60 (Backus et al. 1963), i.e., it contains ALGOL 60 as a subset. As a programming language, apart from simulation, SIMULA has extensive list processing facilities and introduces an extended co-routine concept in a high-level language.

Dahl and Nygaard go on to state the importance of specific languages for simulation (1966) as follows:

Simulation is now a widely used tool for analysis of a variety of phenomena: nerve networks, communication systems, traffic flow, production systems, administrative systems, social systems, etc. Because of the necessary list processing, complex data structures and program sequencing demands, simulation programs are comparatively difficult to write in machine language or in ALGOL or FORTRAN. This alone calls for the introduction of simulation languages.

However, still more important is the need for a set of basic concepts in terms of which it is possible to approach, understand and describe all the apparently very different phenomena listed above. A simulation language should be built around such a set of basic concepts and allow a formal description which may generate a computer program. The language should point out similarities and differences between systems and force the research worker to consider all relevant aspects of the systems. System descriptions should be easy to read and print and hence useful for communication.

Again, according to Dahl and Nygaard (2001),

SIMULA I (1962–1965) and Simula 67 (1967) are the two first object-oriented languages. Simula 67 introduced most of the key concepts of object-oriented programming: both objects and classes, subclasses (usually referred to as inheritance) and virtual procedures, combined with safe referencing and mechanisms for bringing into a program collections of program structures described under a common class heading (prefixed blocks).

The Simula languages were developed at the Norwegian Computing Center, Oslo, Norway by Ole-Johan Dahl and Kristen Nygaard. Nygaard’s work in Operational Research in the 1950s and early 1960s created the need for precise tools for the description and simulation of complex man–machine systems. In 1961 the idea emerged for developing a language that both could be used for system description (for people) and for system prescription (as a computer program through a compiler). Such a language had to contain an algorithmic language, and Dahl’s knowledge of compilers became essential…When the inheritance mechanism was invented in 1967, Simula 67 was developed as a general programming language that also could be specialised for many domains, including system simulation.

Generally, object-oriented classes are used to define agent templates, and instantiated objects are used to implement specific agents. Agent environment templates and spatial relationship patterns are also typically implemented using classes. Recursive environment nesting and abstract spaces, physical spaces, and connectedness can all be represented in relatively straightforward ways. Instantiated objects are used to implement specific agent environments and spatial relationships in individual models. Within these models, model configurations are also commonly implemented as objects instantiated from one or more classes. However, as with unstructured and structured languages, object-oriented languages generally do not provide special support for application data configuration, collection of outputs, or analysis of results. As such, these tasks usually need to be manually implemented by model developers. Regardless of this, the ability to bind data and procedures provides such a straightforward method for implementing agents that most agent-based models are written using object-oriented languages.

It should be noted that traditional object-oriented languages do not provide a means to modify class and object structures once a program begins to execute. Newer “dynamic” object-oriented languages such as Groovy (Koenig et al. 2007) offer this capability. This potentially allows agents to gain and lose attributes and methods during the execution of a model based on the flow of events in a simulation. This in turn offers the possibility of implementing modules with fuzzy boundaries that are flexible enough to change structure over time.

As discussed in the previous section, logic-based languages offer an alternative to the progression formed by unstructured, structured, and object-oriented languages. Logic-based languages can provide a form of direct support for binding data (e.g., asserted propositions) with actions (e.g., logical predicates), sometimes including the use of higher-order programming. In principle, each agent can be implemented as a complex predicate with multiple nested sub-terms. The sub-terms, which may contain unresolved variables, can then be activated and resolved as needed during model execution. Agent templates which are analogous to object-oriented classes can be implemented using the same approach but with a larger number of unresolved variables. Agent environments and the resulting relationships between agents can be formed in a similar way. Since each of these constructs can be modified at any time, the resulting system can change structure over time and may even allow fuzzy boundaries. In practice this approach is rarely, if ever, used. As with the previously discussed approaches, logic-based languages usually do not provide special support for application data configuration, output collection, or results analysis so these usually need to be manually developed.

Functional languages offer yet another alternative to the previously discussed languages. Like logic-based and object-oriented languages, functional languages often provide a form of direct support for binding data with behaviors. This support often leverages the fact that most functional languages support higher-order programming. As a result, the data is usually in the form of nested lists of values and functions, while the behaviors themselves are implemented in the form of functions. Agent templates (i.e., “classes”), agent environments, and agent relationships can be implemented similarly. Each of the lists can be dynamically changed during a simulation run so the model structure can evolve and can potentially have fuzzy boundaries. Unlike the other languages discussed so far, a major class of functional languages, namely, those designed for computational mathematics, usually include sophisticated support for program output collection and results analysis. An example is Mathematica (Wolfram 2013). If the application data is configured in mathematically regular ways, then these systems may also provide support for application data setup.

Example Computer Languages Useful for Agent-Based Modeling

Design Languages

Design languages provide a way to describe models at a more abstract level than typical programming languages. Some design languages ultimately offer the opportunity to compile to executable code. Other design languages act as intermediate stages between initial conceptualization and compliable implementation. In either case, the resulting design documents can be used to describe the model once they are complete.

Design Patterns

Patterns have offered a powerful yet simple way to conceptualize and communicate ideas in many disciplines since Christopher Alexander introduced them in the late 1970s (Alexander et al. 1977; Alexander 1979). Design patterns form a “common vocabulary” describing tried-and-true solutions for commonly faced software design problems (Coplien 2001). Software design patterns were popularized by Gamma et al. (1995). They have subsequently been shown to be of substantial value in improving software quality and development efficiency. Several authors, such as North and Macal (2011), have suggested that there is great potential for patterns to improve the practice of agent-based modeling as well. North and Macal (2013) discussed product and process patterns. Product patterns are a vocabulary for designing or implementing models. Process patterns are methods for designing, implementing, or using models.

According to Alexander (1979), “each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.” The first part of a pattern characterizes the situation in which the problem occurs. The second part defines the problem to be solved. The third part describes a resolution to the outstanding issue as well as its positive and negative consequences. Every pattern has both fixed and variable elements. The fixed elements define the pattern. The variable elements allow the pattern to be adapted for each situation. Each pattern identifies a set of decisions to make in the development of a system. Sets of patterns that have been adapted for the situation are then used as a vocabulary to describe solutions to problems. North and Macal (2013) introduce a catalog of patterns specifically for agent-based modeling. An example from North and Macal (2013) is shown in Table 1.
Table 1

The scheduler scramble product design pattern

Name: Scheduler scramble

Problem: How can multiple agents act during the same scheduler pattern clock tick without biasing the model results or giving a long-term advantage or disadvantage to any one agent?

Context: Two or more agents from the agent-based model pattern may attempt to simultaneously execute behaviors during the same clock tick

Forces: Activating a behavior before other agents can be either an artificial advantage or disadvantage for the agent that goes first. Agent rules should not have to include coordination functions

Solution: The competing behaviors at each clock tick are scheduled in a random order. This is a simulation pattern

Resulting context: A sequential behavioral activation order with long-term fairness and that is unbiased is produced

ODD Protocol

Grimm et al.’s (2006) ODD protocol describes models using a three-part approach: overview, concepts, and details. The model overview includes a statement of the model’s intent, a description of the main variables, and a discussion of the agent activities. The design concepts include a discussion of the foundations of the model. The details include the initial setup configuration, input value definitions, and descriptions of any embedded models. The resulting natural language document cannot be translated directly into executable code. However, it provides a basis for describing the design of models for publications, user documentation, and model development programmers.


The Unified Modeling Language (UML) (Object Management Group 2001; Object Management Group 2013) is a predominantly visual approach to specifying the design of software. UML is particularly useful since it is flexible, general, and independent of particular programming languages. UML is widely supported by a wide range of software development environments (Object Management Group 2013). Some of these environments can compile fully specified UML diagrams to executable code.

The UML standard defines several types of diagrams that together provide a powerful and widely accepted approach to software design. These diagram types include use case diagrams, state diagrams, activity diagrams, class diagrams, and object diagrams (North and Macal 2007). A combination of these diagram types can be used to fully document both the underlying knowledge and the resulting designs of agent-based models.

Domain-Specific Languages

Domain-specific languages (DSLs) are computer languages that are highly customized to support a well-defined application area or “domain.” DSLs commonly include a substantial number of keywords that are nouns and verbs in the area of application as well as overall structures and execution patterns that correspond closely with the application area. DSLs are intended to allow users to write in a language that is closely aligned with their area of expertise.

DSLs often gain their focus by losing generality. For many DSLs, there are activities that can be programmed in most computer languages that cannot be programmed in the given DSL. This is consciously done to simplify the DSL’s design and make it easier to learn and use. If a DSL is properly designed, then the loss of generality is often inconsequential for most uses since the excluded activities are chosen to be outside the normal range of application. However, even the best designed DSLs can occasionally be restrictive when the bounds of the language are encountered. Some DSLs provide special extension points that allow their users to program in a more general language such as C or Java when the limits of the DSL are reached. This feature is extremely useful, but requires more sophistication on the part of the user in that they need to know and simultaneously use both the DSL and the general language.

DSLs have the potential to implement specific features to support design patterns within a given domain. (North and Macal 2011, 2013) describe agent-based modeling design patterns in greater depth.

In principle, DSLs can be unstructured, structured, object oriented, logic based, or functional. In practice, DSLs are often structured languages or object-oriented languages and occasionally are functional languages. Commonly used ABM DSLs include business-oriented languages (e.g., spreadsheet programming tools), science and engineering languages (e.g., Mathematica), and dedicated agent-based modeling languages (e.g., NetLogo and Repast Simphony ReLogo).

Business Languages

Some of the most widely used business computer languages are those available in spreadsheet packages. Spreadsheets are usually programmed using a “macro language.” As discussed further in North and Macal (2007), any modern spreadsheet program can be used to do basic agent-based modeling. The most common convention is to associate each row of a primary spreadsheet worksheet with an agent and use consecutive columns to store agent properties. Secondary worksheets are then used to represent the agent environment and to provide temporary storage for intermediate calculations. A simple loop is usually used to scan down the list of agents and to allow each one to execute in turn. The beginning and end of the scanning loop are generally used for special setup activities before and special cleanup activities after each round. An example agent spreadsheet from North and Macal (2007) is shown in Fig. 1. Agent spreadsheets have both strengths and weaknesses compared to the other ABM tools. Agent spreadsheets tend to be easy to build but they also tend to have limited capabilities. This balance makes spreadsheets ideal for agent-based model exploration, scoping, and prototyping. Simple agent models can be implemented on the desktop using environments outside of spreadsheets as well (Fig. 2).
Fig. 1

An example agent spreadsheet (North and Macal 2007)

Fig. 2

An example agent spreadsheet code (North and Macal 2007)

Science and Engineering Languages

Science and engineering languages embodied in commercial products such as Mathematica, MATLAB, Maple, and others can be used as a basis for developing agent-based models. Such systems usually have a large user base, are readily available on desktops, and are widely integrated into academic training programs. They can be used as rapid prototype development tools or as components of large-scale modeling systems. Science and engineering languages have been applied to agent-based modeling. Their advantages include a fully integrated development environment, their interpreted (as opposed to compiled) nature providing immediate feedback to users during the development process, and a packaged user interface. Integrated tools provide support for data import and graphical display. Macal (2004) describes the use of Mathematica and MATLAB in agent-based simulation, and Macal and Howe (2005) detail investigations into linking Mathematica and MATLAB to the Repast ABM toolkit to make use of Repast’s simulation scheduling algorithms. In the following sections, we focus on MATLAB and Mathematica as representative examples of science and engineering languages.

MATLAB and Mathematica are both examples of Computational Mathematics Systems (CMS). CMS allow users to apply powerful mathematical algorithms to solve problems through a convenient and interactive user interface. CMS typically supply a wide range of built-in functions and algorithms. MATLAB, Mathematica, and Maple are examples of commercially available CMS whose origins go back to the late 1980s. CMS are structured in two main parts: (1) the user interface that allows dynamic user interaction and (2) the underlying computational engine, or kernel, that performs the computations according to the user’s instructions. Unlike conventional programming languages, CMS are interpreted instead of compiled, so there is immediate feedback to the user, but some performance penalty is paid. The underlying computational engine is written in the C programming language for these systems, but C coding is unseen by the user. The most recent releases of CMS are fully integrated systems, combining capabilities for data input and export, graphical display, and the capability to link to external programs written in conventional languages such as C or Java using inter-process communication protocols. The powerful features of CMS, their convenience of use, the need to learn only a limited number of instructions on the part of the user, and the immediate feedback provided to users are features of CMS that make them good candidates for developing agent-based simulations.

A further distinction can be made among CMS. A subset of CMS are what is called Computational Algebra Systems (CAS). CAS are computational mathematics systems that calculate using symbolic expressions. CAS owe their origins to the LISP programming language, which was the earliest functional programming language (McCarthy 1960). Macsyma (www.scientek.com/macsyma) and Scheme (Springer and Freeman 1989) (www.swiss.ai.mit.edu/projects/scheme) are often mentioned as important implementations leading to present-day CAS. Typical uses of CAS are equation solving, symbolic integration and differentiation, exact calculations in linear algebra, simplification of mathematical expressions, and variable precision arithmetic. Computational mathematics systems consist of numeric processing systems or symbolic processing systems, or possibly a combination of both. Especially when algebraic and numeric capabilities are combined into a multi-paradigm programming environment, new modeling possibilities open up for developing sophisticated agent-based simulations with minimal coding.


Mathematica is a commercially available numeric processing system with enormous integrated numerical processing capability (http://www.wolfram.com). Beyond numeric processing, Mathematica is a fully functional programming language. Unlike MATLAB, Mathematica is a symbolic processing system that uses term replacement as its primary operation. Symbolic processing means that variables can be used before they have values assigned to them; in contrast, a numeric processing language requires that every variable have a value assigned to it before it is used in the program. In this respect, although Mathematica and MATLAB may appear similar and share many capabilities, Mathematica is fundamentally much different than MATLAB, with a much different style of programming and ultimately with a different set of capabilities applicable to agent-based modeling.

Mathematica’s symbolic processing capabilities allow one to program in multiple programming styles, either as alternatives or in combination, such as functional programming, logic programming, procedural programming, and even object-oriented programming styles. Like MATLAB, Mathematica is also an interpreted language, with the kernel of Mathematica running in the background in C. In terms of data types, everything is an expression in Mathematica. An expression is a data type with a head and a list of arguments in which even the head of the expression is part of the expression’s arguments.

The Mathematica user interface consists of a what is referred to as a notebook (Fig. 3). A Mathematica notebook is a fully integratable development environment and a complete publication environment. The Mathematica application programming interface (API) allows programs written in C, Fortran, or Java to interact with Mathematica. The API has facilities for dynamically calling routines from Mathematica as well as calling Mathematica as a computational engine.
Fig. 3

Example Mathematica cellular automata model

Figure 3 shows Mathematica desktop notebook environment. A Mathematica notebook is displayed in its own window. Within a notebook, each item is contained in a cell. The notebook cell structure has underlying coding that is accessible to the user.

In Mathematica, a network representation consists of combining lists of lists, or more generally expressions of expressions, to various depths. For example, in Mathematica, an agent can be represented explicitly as an expression that includes a head named agent, a sequence of agent attributes, and a list of the agent’s neighbors. Agent data and methods are linked together by the use of what are called “up values.”

Example references for agent-based simulation using Mathematica include Gaylord and Davis (1999), Gaylord and Nishidate (1994), and Gaylord and Wellin (1995). Gaylord and D’Andria (1998) describe applications in social agent-based modeling.


The MATrix LABoratory (MATLAB) is a numeric processing system with enormous integrated numerical processing capability (http://www.mathworks.com). It uses a scripting-language approach to programming. MATLAB is a high-level matrix/array language with control flow, functions, data structures, input/output, and object-oriented programming features. The user interface consists of the MATLAB desktop, which is a fully integrated and mature development environment. MATLAB has an application programming interface (API). The MATLAB API allows programs written in C, Fortran, or Java to interact with MATLAB. There are facilities for calling routines from MATLAB (dynamic linking) as well as routines for calling MATLAB as a computational engine, as well as for reading and writing specialized MATLAB files.

Figure 4 shows the MATLAB desktop environment illustrating the Game of Life, which is a standard MATLAB demonstration. The desktop consists of four standard windows: a command window, which contains a command line, the primary way of interacting with MATLAB; the workspace, which indicates the values of all the variables currently existing in the session; a command history window that tracks the entered command; and the current directory window. Other windows allow text editing of programs and graphical output display.
Fig. 4

Example MATLAB cellular automata model

When it comes to agent-based simulation, as in most types of coding, the most important indicator of the power of a language for modeling is the extent of and the sophistication of the allowed data types and data structures. As Sedgewick observes:

For many applications, the choice of the proper data structure is really the only major decision involved in the implementation; once the choice has been made only very simple algorithms are needed. (Sedgewick 1988)

The flexibility of data types plays an important role in developing large-scale, extensible models for agent-based simulation. In MATLAB the primary data type is the double array, which is essentially a two-dimensional numeric matrix. Other data types include logical arrays, cell arrays, structures, and character arrays.

For agent-based simulations that define agent relationships based on networks, connectivity of the links defines the scope of agent interaction and locally available information. Extensions to modeling social networks require the use of more complex data structures than the matrix structure commonly used for grid representations. Extensions from grid topologies to network topologies are straightforward in MATLAB and similarly in Mathematica. In MATLAB, a network representation consists of combining cell arrays or structures in various ways.

The MATLAB desktop environment showing the Game of Life demonstration appears in Fig. 4. The Game of Life is a cellular automaton invented by mathematician John Conway that involves live and dead cells in cellular automata grid. In MATLAB, the agent environment is a sparse matrix that is initially set to all zeros. Whether cells stay alive, die, or generate new cells depends upon how many of their eight possible neighbors are alive. By using sparse matrices, the calculations required become very simple. Pressing the “Start” button automatically seeds this universe with several small random communities and initiates a series of cell updates. After a short period of simulation, the initial random distribution of live (i.e., highlighted) cells develops into sets of sustainable patterns that endure for generations.

Several agent-based models using MATLAB have been published in addition to the Game of Life. These include a model of political institutions in modern Italy (Bhavnani 2003), a model of pair interactions and attitudes (Pearson and Boudarel 2001), a bargaining model to simulate negotiations between water users (Thoyer et al. 2001), and a model of sentiment and social mitosis based on Heider’s Balance Theory (Guetzkow et al. 1972; Wang and Thorngate 2003). The latter model uses Euler, a MATLAB-like language. Thorngate argues for the use of MATLAB as an important tool to teach simulation programming techniques (Thorngate 2000).

Dedicated Agent-Based Modeling Languages

Dedicated agent-based modeling languages are DSLs that are designed to specifically support agent-based modeling. Several such languages currently exist. These languages are functionally differentiated by the underlying assumptions their designers made about the structures of agent-based models. The designers of some of these languages assume quite a lot about the situations being modeled and use this information to provide users with pre-completed or template components. The designers of other languages make comparatively fewer assumptions and encourage users to implement a wider range of models. However, more work is often needed to build models in these systems. This entry will discuss two selected examples, namely, NetLogo and Repast Simphony flowcharts.


NetLogo is an education-focused ABM environment (Wilensky 1999). The NetLogo language uses a modified version of the Logo programming language (Harvey 1997). NetLogo itself is Java based and is free for use in education and research. More information on NetLogo and downloads can be found at http://ccl.northwestern.edu/netlogo/.

NetLogo is designed to provide a basic computational laboratory for teaching complex adaptive systems concepts. NetLogo was originally developed to support teaching, but it can be used to develop a wider range of applications. NetLogo provides a graphical environment to create programs that control graphic “turtles” that reside in a world of “patches” that is monitored by an “observer.” NetLogo’s DSL is limited to its turtle and patch paradigm. However, NetLogo models can be extended using Java to provide for more general programming capabilities. An example NetLogo model of an ant colony (Wilensky 1999) (center) feeding on three food sources (upper left corner, lower left corner, and middle right) is shown in Fig. 5. Example code (Wilensky 1999) from this model is shown in Fig. 6.
Fig. 5

Example NetLogo ant colony model (Wilensky 1999)

Fig. 6

Example NetLogo code from the ant colony model (Wilensky 1999)

Repast Simphony Flowcharts

The Recursive Porous Agent Simulation Toolkit (Repast) is a free and open source suit of agent-based modeling and simulation library (ROAD 2013). The Repast Suite is a family of advanced, free, and open source agent-based modeling and simulation software that have collectively been under continuous development for over 10 years. Repast Simphony is a richly interactive and easy to learn Java-based modeling environment that is designed for use on workstations and small computing clusters. Repast for high-performance computing (HPC) is a lean and expert-focused C++-based modeling library that is designed for use on large computing clusters and supercomputers. Repast Simphony and Repast HPC share a common architecture. Information on the Repast Suite and free downloads can be found at http://repast.sourceforge.net/.

Repast Simphony (North et al. 2013) includes advanced features for specifying, executing, and analyzing agent-based simulations. Repast Simphony offers several methods for specifying agents and agent environments including visual specification, specification with the dynamic object-oriented Groovy language (Koenig et al. 2007), and specification with Java. In principle, Repast Simphony’s visual DSL can be used for any kind of programming, but models beyond a certain level of complexity are better implemented in Groovy or Java. As discussed later, Groovy and Java are general-purpose languages. All of Repast Simphony’s languages can be fluidly combined in a single model. An example Repast Simphony zombie model is shown in Fig. 7 (North et al. 2013). In all cases, the user has a choice of a visual rich point-and-click interface or a “headless” batch interface to execute models (Fig. 8).
Fig. 7

Example Repast Simphony zombie model (North et al. 2013)

Fig. 8

Example Repast Simphony visual behavior from a zombie model (North et al. 2013)

General Languages

Unlike DSLs, general languages are designed to take on any programming challenge. However, in order to meet this challenge, they are usually more complex than DSLs. This tends to make them more difficult to learn and use. Lahtinen et al. (2005) document some of the challenges users face in learning general-purpose programming languages. Despite these issues, general-purpose programming languages are essential for allowing users to access the full capabilities of modern computers. Naturally, there are a huge number of general-purpose programming languages. This entry considers these options from two perspectives. First, general language toolkits are discussed. These toolkits provide libraries of functions to be used in a general-purpose host language. Second, the use of three raw general-purpose languages, namely, Java, C#, and C++, is discussed.

General Language Toolkits

As previously stated, general language toolkits are libraries that are intended be used in a general-purpose host language. These toolkits usually provide model developers with software for functions such as simulation time scheduling, results visualization, results logging, and model execution as well as domain-specific tools (North et al. 2006). Users of raw general-purpose languages have to write all of the needed features by themselves by hand.

A wide range of general language toolkits currently exist. This entry will discuss two selected examples, namely, Swarm and the Groovy and Java interfaces for Repast Simphony.

Swarm (Minar et al. 1996; Swarm Development Group 2013) is a free and open source agent-based modeling library. Swarm seeks to create a shared simulation platform for agent modeling and to facilitate the development of a wide range of models. Users build simulations by incorporating Swarm library components into their own programs. Information on Swarm and free downloads can be found at http://www.swarm.org/ From Marcus Daniels (Daniels 1999),

Swarm is a set of libraries that facilitate implementation of agent-based models. Swarm’s inspiration comes from the field of Artificial Life. Artificial Life is an approach to studying biological systems that attempts to infer mechanism from biological phenomena, using the elaboration, refinement, and generalization of these mechanisms to identify unifying dynamical properties of biological systems…To help fill this need, Chris Langton initiated the Swarm project in 1994 at the Santa Fe Institute. The first version was available by 1996, and since then it has evolved to serve not only researchers in biology, but also anthropology, computer science, defense, ecology, economics, geography, industry, and political science.

The Swarm simulation system has two fundamental components. The core component runs general-purpose simulation code written in Objective-C, Tcl/Tk, and Java. This component handles most of the behind-the-scenes details. The external wrapper components run user-specific simulation code written in either Objective-C or Java. These components handle most of the center stage work. An example Swarm supply chain model is shown in Fig. 9.
Fig. 9

Example Swarm supply chain model (Swarm Development Group 2013)

Repast Simphony Java and Groovy

As previously discussed, Repast which is a suite is a free and open source of agent-based modeling and simulation software (ROAD 2013). Information on the Repast Suite and free downloads can be found at http://repast.sourceforge.net/. The Java-based Repast Simphony environment includes advanced features for specifying, executing, and analyzing agent-based simulations. An example Repast Simphony zombie model is shown in Fig. 7 (North et al. 2013).

Repast Simphony offers several intermixable methods for specifying agents and agent environments including visual specification, specification with the dynamic object-oriented Groovy language (Koenig et al. 2007), and specification with Java. The Groovy approach uses the dynamic object-oriented Groovy language as shown in Fig. 10. The Java approach for an example Zombie is shown in Fig. 11.
Fig. 10

Example Repast Simphony Groovy code from a zombie model (North et al. 2013)

Fig. 11

Example Repast Simphony Java code from a zombie model North et al. 2013)


Java (Foxwell 1999) is a widely used object-oriented programming language that was developed and is maintained by Oracle Corporation. Java is known for its widespread “cross-platform” availability on many different types of hardware and operating systems. This capability comes from Java’s use of a “virtual machine” that allows binary code or “bytecode” to have a consistent execution environment on many different computer platforms. A large number of tools are available for Java program development including the powerful Eclipse development environment (2013) and many supporting libraries. Java uses reflection and dynamic method invocation to implement a variant of higher-order programming. Reflection is used for runtime class structure examination, while dynamic method invocation is used to call newly referenced methods at runtime. Java’s object orientation, cross-platform availability, reflection, and dynamic method invocation along with newer features such as annotations for including metadata in compiled code, generics for generalizing class, and aspects to implement dispersed but recurrent tasks make it a good choice for agent-based model development.


C# (Archer 2001) is an object-oriented programming language that was developed and is maintained by Microsoft. C# is one of many languages that can be used to generate Microsoft.NET Framework code or Common Intermediate Language (CIL). Like Java bytecode, CIL is run using a “virtual machine” that potentially gives it a consistent execution environment on different computer platforms. A growing number of tools are emerging to support C# development. C# and the Microsoft.NET Framework more generally are in principle cross-platform, but in practice they are mainly executed under Microsoft Windows.

The Microsoft.NET Framework provides for the compilation into CIL of many different languages such as C#, Managed C++, and Managed Visual Basic to name just a few. Once these languages are compiled to CIL, the resulting modules are fully interoperable. This allows users to conveniently develop integrated software using a mixture of different languages. Like Java, C# supports reflection and dynamic method invocation for higher-order programming. C#’s object orientation, multilingual integration, generics, attributes for including metadata in compiled code, aspects, reflection, and dynamic method invocation make it well suited for agent-based model development, particularly on the Microsoft Windows platform.


C++ is a widely used object-oriented programming language that was created by Bjarne Stroustrup (Stroustrup 2008) at AT&T. C++ is widely noted for both its object-oriented structure and its ability to be easily compiled into native machine code. C++ gives users substantial access to the underlying computer but also requires substantial programming skills.

Most C++ compilers are actually more properly considered C/C++ compilers since they can compile non-object-oriented C code as well as object-oriented C++ code. This allows sophisticated users the opportunity to highly optimize selected areas of model code. However, this also opens the possibility of introducing difficult-to-resolve errors and hard-to-maintain code. It is also more difficult to port C++ code from one computer architecture to another than it is for virtual machine-based languages such as Java.

C++ can use a combination of Runtime Type Identification (RTTI) and function pointers to implement higher-order programming. Similar to the Java approach, C++ RTTI can be used for runtime class structure examination, while function pointers can be used to call newly referenced methods at runtime. C++’s object orientation, RTTI, function pointers, and low-level machine access make it a reasonable choice for the development of extremely large or complicated agent-based models.

Future Directions

Future developments in computer languages could have enormous implications for the development of agent-based modeling. Some of the challenges of agent-based modeling for the future include (1) scaling up models to handle large numbers of agents running on distributed heterogeneous processors across the grid, (2) handling the large amounts of data generated by agent models and making sense out of it, and (3) developing user-friendly interfaces and modular components in a collaborative environment that can be used by domain experts with little or no knowledge of standard computer coding techniques. Visual and natural language development environments that can be used by nonprogrammers are continuing to advance but remain to be proven at reducing the programming burden. There are a variety of next steps for the development of computer languages for agent-based modeling including the further development of DSLs, increasing visual modeling capabilities, and the development of languages and language features that better support pattern-based development. DSLs are likely to become increasingly available as agent-based modeling grows into a wider range of domains. More agent-based modeling systems are developing visual interfaces for specifying model structures and agent behaviors. Many of these visual environments are themselves DSLs. The continued success of agent-based modeling will likely yield an increasing number of design patterns. Supporting and even automating implementations of these patterns may form a natural source for new language features. Many of these new features are likely to be implemented within DSLs.


  1. Alexander C (1979) The timeless way of building. Oxford University Press, OxfordGoogle Scholar
  2. Alexander C, Ishikawa S, Silverstein M (1977) A pattern language. Oxford University Press, OxfordGoogle Scholar
  3. Archer T (2001) Inside C#. Microsoft Press, RedmondGoogle Scholar
  4. Backus J, Bauer F, Green J, Katz C, McCarthy J, Naur P, Perlis A, Rutishauser H, Samuelson K, Vauquois B, Wegstein J, van Wijngaarden A, Woodger M (1963) Revised report on the algorithmic language ALGOL 60. In: Naur P (ed) Communications of the association for computing machinery (ACM), vol 6. ACM, New York, pp 1–17Google Scholar
  5. Bhavnani R (2003) Adaptive agents, political institutions and civic traditions in modern Italy. JASSS 6(4). Available at http://jasss.soc.surrey.ac.uk/6/4/1.html
  6. Bonabeau E (2001) Agent-based modeling: methods and techniques for simulating human systems. Proc Natl Acad Sci 99(3):7280–7287ADSGoogle Scholar
  7. Casti J (1997) Would-be worlds: how simulation is changing the world of science. Wiley, New YorkzbMATHGoogle Scholar
  8. Coplien J (2001) Software patterns home page. Available at http://hillside.net/patterns/
  9. Dahl O-J, Nygaard K (1966) SIMULA – an ALGOL-based simulation language. Commun ACM 9:671–678zbMATHCrossRefGoogle Scholar
  10. Dahl O-J, Nygaard K (2001) How object-oriented programming started. Available at http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html
  11. Daniels M (1999) Integrating simulation technologies with swarm. In: Proceedings of the agent 1999 workshop on agent simulation: applications, models, and tools. Argonne National Laboratory, ArgonneGoogle Scholar
  12. Dijkstra E (1968) Go to statement considered harmful. Commun ACM 11(3):147–148MathSciNetCrossRefGoogle Scholar
  13. Eclipse (2013) Eclipse home page. Available at http://www.eclipse.org/
  14. Foxwell H (1999) Java 2 software development kit. Linux JGoogle Scholar
  15. Gamma E, Helm R, Johnson R, Vlissides J (1995) Design patterns: elements of reusable object-oriented software. Addison-Wesley, WokinghamGoogle Scholar
  16. Gaylord R, D’Andria L (1998) Simulating society: a Mathematica toolkit for modeling socioeconomic behavior. Springer/TELOS, New YorkzbMATHCrossRefGoogle Scholar
  17. Gaylord R, Davis J (1999) Modeling nonspatial social interactions. Math Educ Res 8(2):1–4Google Scholar
  18. Gaylord R, Nishidate K (1994) Modeling nature: cellular automata simulations with Mathematica. Springer, New YorkGoogle Scholar
  19. Gaylord R, Wellin P (1995) Computer simulations with Mathematica: explorations in complex physical and biological systems. Springer/TELOS, New YorkzbMATHGoogle Scholar
  20. Grimm V et al (2006) A standard protocol for describing individual-based and agent-based models. Ecol Model 198(1–2):115–126CrossRefGoogle Scholar
  21. Guetzkow H, Kotler P, Schultz R (eds) (1972) Simulation in social and administrative science. Prentice Hall, Englewood CliffsGoogle Scholar
  22. Harvey B (1997) Computer science logo style. MIT Press, BostonGoogle Scholar
  23. Heath J (2005) Methodological individualism. In: Zalta E (ed) Stanford encyclopedia of philosophy. Stanford University, Stanford. Available at http://plato.standford.edu/
  24. Jennings N (2000) On agent-based software engineering. Artif Intel 117:277–296CrossRefGoogle Scholar
  25. Koenig D, Glover A, King P, Laforge G, Skeet J (2007) Groovy in action. Manning Publications, GreenwichGoogle Scholar
  26. Lahtinen E, Ala-Mutka K, Jarvinen H-M (2005) A study of the difficulties of novice programmers. In: Proceedings of the 10th annual SIGCSE conference on innovation and technology in computer science education. ACM, CaparicaGoogle Scholar
  27. Macal C (2004) Agent-based modeling and social simulation with mathematica and MATLAB. In: Macal C, Sallach D, North M (eds) Proceedings of the agent 2004 conference on social dynamics: interaction, reflexivity and emergence. Argonne National Laboratory, ArgonneGoogle Scholar
  28. Macal C, Howe T (2005) Linking repast to computational mathematics systems: Mathematica and MATLAB. In: Macal C, Sallach D, North M (eds) Proceedings of the agent 2005 conference on generative social processes, models, and mechanisms. Argonne National Laboratory, ArgonneGoogle Scholar
  29. Macal C, North M (2007) Agent-based modeling and simulation: desktop ABMS. In: Henderson SG, Biller B, Hsieh M-H, Shortle J, Tew JD, Barton RR (eds) Proceedings of the 2007 winter simulation conference. IEEE/ACM, Washington, DCGoogle Scholar
  30. McCarthy J (1960) Recursive functions of symbolic expressions and their computation by machine I. J ACM 3:184–195, ACM, New York, NY, USAzbMATHCrossRefGoogle Scholar
  31. Minar N, Burkhart R, Langton C, Askenazi M (1996) The swarm simulation system: a toolkit for building multi-agent simulations. Available at http://alumni.media.mit.edu/~nelson/research/swarm/
  32. North M, Macal C (2007) Managing business complexity: discovering strategic solutions with agent-based modeling and simulation. Oxford University Press: New York, NY, USAGoogle Scholar
  33. North M, Macal C (2011) Product design patterns for agent-based modeling. In: Jain S, Creasey R, Himmelspach J (eds) Proceedings of the 2011 winter simulation conference. IEEE/ACM, PhoenixGoogle Scholar
  34. North M, Macal C (2013) Product and process patterns for agent-based modeling and simulation. J Simulat 8:25–36Google Scholar
  35. North M, Collier N, Vos R (2006) Experiences creating three implementations of the repast agent modeling toolkit. In: ACM transactions on modeling and computer simulation, vol 16, Issue 1. ACM, New York, pp 1–25Google Scholar
  36. North M, Collier N, Ozik J, Tatara E, Altaweel M, Macal M, Bragen M, Sydelko P (2013) Complex adaptive systems modeling with repast simphony. In: Complex adaptive systems modeling. Springer, HeidelbergGoogle Scholar
  37. Object Management Group (2001) OMG unified modeling language specification version 1.5. Object Management Group, NeedhamGoogle Scholar
  38. Object Management Group (2013) Object management group UML home page. Object Management Group, NeedhamGoogle Scholar
  39. Pearson D, Boudarel M-R (2001) Pair interactions: real and perceived attitudes. JASSS 4(4). Available at http://www.soc.surrey.ac.uk/JASSS/4/4/4.html
  40. Reynolds J (1998) Definitional interpreters for higher-order programming. In: Higher-order and symbolic computation. Kluwer, Dordrecht, pp 363–397Google Scholar
  41. ROAD (2013) Repast home page. Available at http://repast.sourceforge.net/
  42. Sedgewick R (1988) Algorithms, 2nd edn. Addison-Wesley, Reading, p 657Google Scholar
  43. Springer G, Freeman D (1989) Scheme and the art of programming. McGraw-Hill, New YorkGoogle Scholar
  44. Stevens W, Meyers G, Constantine L (1974) Structured design. IBM Syst J 13(2):115CrossRefGoogle Scholar
  45. Stroustrup B (2008) Bjarne Stroustrup’s FAQ. Available at http://www.research.att.com/~bs/bs_faq.html#invention
  46. Swarm Development Group home page (2013) Available at http://www.swarm.org/
  47. Thorngate W (2000) Teaching social simulation with MATLAB. JASSS 3(1). Available at http://www.soc.surrey.ac.uk/JASSS/3/1/forum/1.html
  48. Thoyer S, Morardet S, Rio P, Simon L, Goodhue R, Rausser G (2001) A bargaining model to simulate negotiations between water users. JASSS 4(2). Available at http://www.soc.surrey.ac.uk/JASSS/4/2/6.html
  49. Van Roy P, Haridi S (2004) Concepts, techniques, and models of computer programming. MIT Press, CambridgeGoogle Scholar
  50. Wang Z, Thorngate W (2003) Sentiment and social mitosis: implications of Heider’s balance theory. JASSS 6(3) Available at http://jasss.soc.surrey.ac.uk/6/3/2.html
  51. Watson D (1989) High-level languages and their compilers. Addison-Wesley, WokinghamzbMATHGoogle Scholar
  52. Wilensky U (1999) NetLogo http://ccl.northwestern.edu/netlogo/. Center for connected learning and computer-based modeling, Northwestern University, Evanston
  53. Wolfram Research (2013) Mathematica home page. Available at http://www.wolfram.com/

Copyright information

© Springer Science Business Media New York (outside the USA) 2014

Authors and Affiliations

  1. 1.Argonne National LaboratoryGlobal Security Sciences DivisionArgonneUSA