There are simulation tools that require you to define your model entirely in the form of a program, or source code – whether via an existing general purpose programming language or a special purpose simulation language. Other tools require you to define models totally through data: graphical, tabular, or some combination of the two. This is usually a selling point – “no programming required!!!” Finally, there are packages that combine both approaches.
Is “No programming required!” a bug or a feature? That’s a religious question that I’d rather avoid, at least for now. Let it suffice to say that I believe that program code has its place – but then again, I develop software for a living, so perhaps I’m just a bit biased. In any event, I fall into that third camp – both data and code. For now, the question I’d like to explore is not whether modelers should write code, but how and what kind.
A few initial requirements come to mind:
- The language syntax should allow the modeler to naturally express agent or process behavior that takes place over a length of (simulated) time; i.e., actions that may block for a period of simulated time (such as contested resource acquisition), and explicit delays or waits.
- The modeler should be able to create, edit, browse, search, debug and run all of a model’s source code in a full-featured integrated development environment (IDE).
- The modeler should be able to manage source code through any modern version control system.
- The modeler should be able to use, via import, a wide variety of built-in and/or third party libraries in their code.
As mentioned above, modeling code can take the form of either a domain-specific simulation language (DSL) or a general purpose programming language. When we evaluate these two approaches, we see a tension between the first requirement and the others, particularly (2) and (4).
A simulation DSL is, pretty much by definition, designed to express process and/or agent behaviors using domain language. Meeting the other requirements is more of a challenge. Developing IDEs, debuggers and libraries from scratch entails an enormous effort. Depending on the design of the DSL, it may be possible to leverage an existing general-purpose tool chain, but some trade-offs are almost inevitable. In other words, the advantages of a DSL are likely to be at least partially offset by a less than state-of-the-art programming and runtime environment.
Modern, mainstream programming languages, on the other hand, come with a rich ecosystem of tools and libraries – in other words, they fully support requirements 2-4 pretty much out of the box. The first requirement is, however, significantly more problematic. I’d like to be able to define a process as a single block of code that expresses delay and blocking actions through function calls such as wait() or acquireResource(). Until relatively recently, it seemed virtually impossible to do that without using threads – a heavyweight solution that quickly introduces significant problems in both performance and scalability.
Enter coroutines. A coroutine – with the ability to yield to other coroutines, and then be restarted at the point where it left off – provides the key mechanisms we need to implement blocking or delay actions in a simulation process, while costing orders of magnitude less than an operating system thread. Coroutines have been around for more than fifty years, but have only made their way into the mainstream over the past decade or so.
For me, designing and implementing a new simulation DSL has never been an option; that’s one wheel I have neither the skills nor the desire to re-invent. Once I started looking at coroutines – and in particular, the ways in which they are implemented in Python – another path forward began to emerge.