(Please note – this is a draft essay, and may be updated)
In working with Ken Webb on our model of the dynamics of exploitation, we’ve recently been discussing the best way in which to present the model we’ve developed to other researchers. One of our goals on this front is for the model description to be abstract enough that it is not tied to any one specific technical implementation or platform, even though it is a programmatic model (i.e. designed and implemented using computer code). This goal has, in turn, led to discussions about the nature of programmatic models, and in particular, the ways in which they do and do not differ from mathematical models, and how this might influence our presentation of the exploitation model.
I present here some preliminary thoughts on these broader questions, none of which are intended to be particularly novel or conclusive at this point. It’s also likely that I’m retreading old ground that has already been discussed by modellers elsewhere, so this represents my own starting thoughts in this issue, which I hope to expand through further research.
Some Pre-Cursor Thoughts Mostly Relating to Modelling and Mathematical Techniques
We can usefully differentiate between description and instruction. Descriptions provide us with statements of fact, which may be true or false. Instructions provide us with statements that are commanding – they tell us to do something, and are not obviously true or false (although the extent to which they can be thought of as true or false has been a matter for debate in analytic philosophy circles).
Consider:
Descriptive: The cookies are made from flour, eggs and sugar.
Descriptive: He put the cookies in the even for 45 minutes.
Imperative: Put the cookies in the oven for 45 minutes.
Here we might say that the descriptive statements have a static sensibility – they provide information about states of affairs – whereas the imperative statement is a speech act commanding that an action be performed – it is a directive. As such, it is in close company with statements such as performative utterances, as proposed by Austin. A directive commands action, and, if not strictly dynamic in and of itself, if carried out results in action. In this sense it has a more dynamic sensibility than descriptive statements.
This linguistic distinction is at least similar to, if not the same as, a distinction that is made in computer science, which describes computer languages as either declarative or imperative. Declarative programming presents a program as a series of statements that describe an intended situation, but do not tell the computer how to act over the statements. There may be a particular structure¸ or order, to the descriptive statements, but nothing within the description itself states how this structure should be translated into a particular sequence of actions. This is in contrast with imperative programming, which instead directly provides a series of instructions to the computer, which are intended to be carried out in a particular sequence, and which may include branching and looping statements that proscribe a particular path through the instructions based on certain states of the computer at any given moment.
Both types of programs retain a central feature of programming languages, which is that, given certain inputs, including the program itself, along with possibly some data or additional input parameters, an output is produced by having the computer run the program. Declarative programs might be run through the use of additional underlying programs that could, to take one example, carry out logical deduction, along with other logical and mathematical operations (e.g. statement parsing, truth assignments, variable assignments) over the statements of the declarative program, and then generate outputs based on these deductions. Imperative programs are run by stepping through the instructions of the program in a certain sequence, carrying out the actions contained in these instructions, and in the process updating the states of variables as the program executes, eventually resulting in the output.
Consider, for the purposes of illustration, two different series of statements that could be used to generate a certain image. The first, declarative:
Six squares, each square the same size as the others, with spacing 1/5 the length of the side of a square on all sides of all the squares. Each square only has one other square beside it (either to the left or right).
The second, imperative:
Draw a square. Calculate 1/5th the length of one side of this square. Start the drawing of the second square here. Move to below the second last square that has been drawn, leaving 1/5th spacing. Repeat the first three instructions until six squares have been drawn.
In order to maintain their declarative nature, declarative languages must avoid certain programmatic behaviours or elements that could have what are referred to as ‘historical’ implications – i.e. instructions that cause the behaviour and subsequent results of the program to depend on the specific history of how the program has been run up to that point. For example, global variables can have this effect, if referenced within functions, because one function changing a global variable at point A can change how another function that references that variable behaves at point B. Thus when program statements are run in different orders, which may occur at different points in the program, depending on the nature of its control flow, there will possibly be different results from running the same line of code – the same instruction. And these results might be difficult to predict merely by looking at the original program statements themselves, dependent as they are on results generated during run time.
Obtaining different results when carrying out instructions in different orders is not restricted to computer programming. Attempting to bake a cake by carrying out the instructions in a randomly chosen order will most likely not result in something edible, or even anything at all, even though the instructions themselves are the same. Nonetheless, in this case we might still be able to guess what will happen given the instruction set. In situations where the flow of actions is complex, the problem of predicting what will happen is exacerbated. Declarative programming seeks to avoid this by removing the flow issue entirely.
Despite this distinction I still find trying to sharply separate descriptive and imperative statements, or declarative and imperative programming languages, for example on the basis of the presence or absence of certain types of actions or elements, a bit difficult. It’s true that providing only description removes a dynamic element that could prove troublesome, but I find myself wondering how much action is really removed from the over-all picture, once necessary secondary programs (e.g. compilers, interpreters) are factored in to the mix. Given this I wonder whether or not, ultimately, these two types of programming paradigms are fundamentally so different after all.
Before considering this question further, I’ll add to the discussion a very brief discussion of mathematical models, systems of equations, and proofs. Based on my somewhat limited experience in this area, I would say that, in general, these are also intended to be declarative, or descriptive, rather than imperative. They consist of a set of mathematical statements which can be used, via the application of deductive logic and more fundamental mathematical laws, to either generate new statements, which also must be true, so long as the logic has been correctly applied, or to find values of variables for which all of the statements in the set will be true.
It can be seen by this quick sketch of mathematical descriptions that declarative programs have a similarity to mathematical models and mathematical proofs, in that they are collections of descriptive statements to which deductive activities can be applied. This is in fact a typically stated goal of declarative languages – to bring computer programming closer to mathematics by making computer programs more like mathematical descriptions.
We can ask, however, if mathematical descriptions are themselves entirely free from the imperative – i.e. from directive statements – as well as the extent to which they are free from action more generally.
Consider, as a first possible example of actions in a mathematical context the act of calculation. Here, the imperative may be allowed to creep in, as can be seen in the following statements:
Add two to three and multiple by six. Take the result of this and subtract four. Take the result of this, and multiply by five.
Since calculation is an activity, we can indeed be directed to carry out this activity. The terms ‘operator’ and ‘mathematical operation’ capture this active sensibility as well. It is worth noting that there are still many different ways in which such calculations could actually be performed (there are many different ways to implement addition, for example), but all must at least be performed, actively, in some way. It is worth noting, as well, that, when provided in the form of a mathematical expression, these operations must be performed in a specified order in order to achieve consistent results (e.g. BEDMAS).
Creating proofs and solving sets of equations also involve activity. In the case of proofs, a bridge from premises to conclusions is constructed, or derived, through the application of the laws of logic, which transform the premises into the desired conclusion. In the case of solving sets of equations, a similar application of mathematical and logical rules leads to statements that describe values, or ranges of values, of variables, such that all of the statements in the set will be true.
Traditionally, the actions and operations that must be undertaken to generate the final desired statements in both of these cases have not, themselves, been generated by a pre-defined set of instructions, but rather are typically undertaken as a more free-wheeling creative human exercise. However, increasingly, computer programs have been created which can carry out these processes in a more mechanical fashion.
This generation of new statements from existing statements results in more description, in the form of new descriptive statements. In this sense, we have returned to our inactive starting point. However, when we take the step of assigning specific mathematical values to variables in the mathematical description, or truth values to statements, we are again performing an action – assignment. And assigning values to variables has, in turn, the effect of kicking off a series of calculations which are, again, activities that lead themselves to further assignments.
In connection with this, assignment also plays a central role in functions, which, from my perspective, can themselves be viewed either statically or dynamically. Statically, a function can be seen as a mapping from one set of values to another. In this way, the function, existing as an abstract mathematical object, can be wholly represented by a description of the mapping. Dynamically, however, we can view a function as a mechanism (or sequence of mathematical operations) that generates an output based on specific inputs, where the output is produced by, first, assigning values to the function variables and then by carrying out calculations which produce a result, which itself can then be assigned to another variable. From this mechanical perspective, functions act to transform sets of values into another value. I believe that in the mathematical domain the first definition of a function may be considered to be more correct, but the second definition seems relevant at least in a pragmatic computational context.
So far, none of this is intended to be novel or controversial, but rather simply intended to povide a review of some aspects of mathematical products and activities with an eye to seeing where activity appears in this context.
Within this description of mathematical activities, imperative statements, or directions, have not been explicitely present, even though actions themselves have been present, and there is often an implicit sense of directives, with regards to carrying out these actions. Explicitely, however, although an expression such as 2 + 2 contains an operator, and there is the potential for some direction – add the two numbers together – its presence in a mathematical description does not mean that the act of adding the two numbers must actually be carried out.
If we turn towards logical statements more generally, however, imperative statements can be explicitely re-introduced.
While truth evaluation is one possible activity to be carried out with logical statments (for example, given A & B if we assign A true and assign B false, then we can deduce that A & B is also false – i.e. we can assign false to the statement A & B), logical statements also provide the possibility of incorporating instructions directly. For example:
(jump up) AND (get down)
IF (it is raining) THEN (take an umbrella)
The IF THEN statement in particular is interesting here, in that, while for other logical operators it is strange to combine imperative and declarative statements:
(eat the cookie) AND (it is raining)
the IF THEN operator works very well in this case, at least in one specific direction – declarative followed by imperative:
IF (you are happy) THEN (clap your hands)
Or, to use a more computer-focused example
IF (the printer is on) THEN (send the file to the printer)
This distinctive feature of the IF THEN has been noted by computer scientists, cognitive scientists and other disciplines that wish to use computers to generate models and other constructs that usefully inform real-word situations and phenomenon. John Hollands genetic algorithms rules system is one example of this. The ACT-R cognitive modelling framework, with its firing production rules is another. Members of the Cognitive Modelling lab are currently researching this (reference link to research to follow).
Getting Into Declarative and Imperative models
I have to admit that, at this point in my thinking, I’m not yet sure what the above discussion implies about declarative and imperative models.
Let’s suppose that a declarative model is a history free description of a target system, containing statements that are all logically consistent with each other and without any explicit action commands or directions, including control logic directions or calculation directions. Such a model might be thought of as being well-behaved, readily understandable and predictable, when put through a process of deduction.
An imperative model on the other hand – for example, a programmatic model implemented in an imperative language, which must be run on the computer to obtain a particular result, or a mechanical model that can be hand cranked in order to determine a particular system state of interest – is one that is history dependent, in the sense that, until it is run, it is difficult if not impossible to predict how it will behave, via deduction or otherwise. In the case of the mechanical model this seems obvious- the model is not constructed of statements, and thus deduction is not an immediate, direct option. In the case of a programmatic model implemented in an imperative language, despite the fact that it consists of a series of logical statements, its control flow description and focus on instruction rather than description, have a similar effect. It’s behaviour remains opaque until it is run.
It is worth noting, I think, that the historical sensitivity of imperative models is typically criticized as being a problematic feature of these models, relative to declarative models (e.g. mathematical models and programmatic models written in declarative languages). However, on the other side of the coin, I wonder if this lack of historical sensitivity also serves to limit what declarative models can actually generate, and by extension, model.
We might ask three questions about declarative models:
Is it always possible to create a declarative model of a target system?
Is it always possible to create a declarative model of a target system that will answer the particular question of interest that we have?
If both of these are always possible in principle, are they typically possible in practice?
In order for us to get any sort of answer about a system from a declarative model, we would need to, first, formulate our result of interest as a statement, and then determine if this statement is consistent or inconsistent with the statements already existing in the declarative model.
My relatively limited knowledge of mathematics suggests to me that there are some systems for which our current declarative modelling capabilities, as described above, may be limited in terms of what they can deduce with respect to the truth value of given statement of interest – for example, in the case of planetary systems of n bodies, it isn’t possible to come up with a solution that can be expressed in a straightforward manner, using a finite number of standard mathematical operations (i.e. it has no ‘closed form’ solution), and so we can’t easily say if a particular statement of interest is consistent or inconsistent with the model.
However, it’s not clear that imperative models would be any more successful. It may be that the behaviour of some types of systems is not readily modelable by any type of model.
In a model of situation where the value of a variable is legitimately dependent in complex ways on other variables it seem possible that a declarative model might also be challenging to use in order to derive new statements via deductive reasoning. For example, suppose the following relationship between two variables existed.
if (at time t=3, a=2) then (at time t=7 a=6) else (a = 1)
It’s possible that this could be precisely described mathematically as a function of a discrete variable. It also seems possible that, having generated this description, it could be difficult to apply mathematical reasoning strategies to these functions of discrete variables, particularly if there were many of them in a single model. In this case, it is not that the system cannot be described using some kind of mathematical description, but rather that it is then difficult to use the resulting description in certain ways, to achieve certain ends.
Unfortunately, none of this tells us if a particular system and the aspects of it in which we are interested can or cannot definitively, in principle, be created using a declarative model. If we knew the answer to this question in a particular situation, and knew that it was at least theoretically possible for a usable declarative model to be made, we might further be able to find a way to transform a given imperative model into a declarative model. Unfortunately, my current relatively limited knowledge of mathematical modelling techniques, as opposed to programmatic ones makes this type of investigation difficult at the present time, but I’m hopeful that further research will find others who have already investigated and found answers to these types of questions.
Separate from this we can consider if there are at least ways to describe imperative models that are separate from the computer languages in which they are implemented. One possible strategy for this is the Xholon framework, developed by Ken, but this will be left for future discussion.