Further to the
discussion of Richard Gabriel’s comments on Lisp and object
orientation, there are all sorts of ideas that were at best latent in
my thinking through the PhD which have been brought into relief by
recent readings. Abelson (also,
I’ve just noticed, a founding member of the Creative Commons) and Sussman’s Structure
and Interpretation of Computer Programs (online text,
videos, SCIP uses the Scheme dialect of Lisp) has
fleshed out a picture of what I’m trying to do as creating
languages for model development. Paul Graham’s collected
writings, largely on or related to Lisp, and in particular “Programming Bottom
Up” focusses on the need for layers of languages. Ongoing
conversation with Mike Abbott is
filling in considerable detail on what exactly constitutes a model. Jean Cunge’s latest paper in the Journal
of Hydroinformatics, “Of data and
models” (subscription required) builds on Abbott’s “On
Definitions” and sheds considerable additional light on certain
matters. Thinking
Skills & Eye Q - Visual Tools for Raising Intelligence [once
again, allconsuming fails
to find this book, despite the fact that it is clearly in the Amazon
database] introduces the term /schema/, apparently used by
psychologists to refer to what I have previously called /conceptual
models/, and which the authors of that book characterise as, “mental
representations of people, objects, situations and events.”
As if to drive home the value of what I’m trying to do, too, I find myself trying to decipher the program source code of an implementation in C of a flood inundation (LISFLOOD) model developed by Paul Bates. The program is small (a prinout runs to some 25 pages), and even smaller when data reading and writing code is eliminated. The problem is not with the quality of the code, but purely with the fact that the code, while it expresses very well to the computer how to simulate flood inundation based on the model, it does not communicate to me, the human trying to get to grips with the structure of the model and of its meaning, anything at all without a huge effort in line-by-line examination.
Abelson & Sussman:
“Programs should be written for people to read, and only incidentally for machines to execute.”
Nowhere is this more clear, than when constructing a tool for building models. There are two major reasons for building models.
- In the process of research: to aid in the development of
understanding of (some part of) a physical system, and to assist in
establishing the truth (or otherwise) of that understanding. - In the process of engineering: to aid in reasoning about the
likely impacts of certain modifications to a physical system without
having to make those modifications, for example.
Cunge draws these out very nicely in “Of data and models”), and also points out that in areas where knowledge is limited, the boundary between these two situations is less clearly defined:
One important category is that of research: when a researcher hypothesises some feature of natural phenomena, by this very hypothesis he is creating a model in his mind, a concept. He is selecting certain signs from the phenomena themselves and merging these to form an expressive sign that appears to be meaningful and true (Abbott 2002a). Then, building a material model (analytical, numerical, laboratory scale, etc.) and comparing the results of the latter with observed data, he can validate or invalidate his hypothesis. The model provides a better understanding of nature in the sense that the comparison can either confirm the acceptability of the image of reality proposed by the researcher or, to the contrary, indicate that the image is not adequate and further developments are necessary. Another category of reasons for becoming so involved are engineering applications. In most cases, when an engineer is building a model, he does it for one of two reasons:
- either he wants to predict the consequences of situations that
have not been observed so far: for example, the consequences of building
hydraulic structures on a river (dams, dykes, etc.), transformation of
an exceptional, never before observed rainfall episode into runoff and
discharge, etc;- or he aims at monitoring or controlling a process during which the
variations are not exceptional but should be correctly forecast: for
example, manufacturing processes, flood control and navigation.
In either case, the human—human communication of the meaning of the model is critical, but almost completely unsupported by available tools which have developed, as with so much modern computer-based tools, in the context of an obsession with the replacement of humans with machines. In fact this approach, now as in the Industrial Revolution, where it presumably has its genesis, does not result in replacement, but in (apparent) “deskilling” — the reduction of jobs to the mindless handle-cranking which leads to so many people working only so that they can feed themselves long enough to have a retirement (whereupon many discover that in fact they were heavily reliant on their work to fill up their time and generate their identity, but that’s another story).
This desire to replace people with machines no doubt interacts heavily (and cyclically, the one reinforcing the other and vice versa) with the tendency to use “computer metaphors” for selfhood which Abbott draws attention to in his paper and returns to in a recent email:
The computer metaphors for the self reflect the sad state of education nowadays, whereby almost all effort goes into the ‘how?’ and almost nothing is left for the ‘why?’.
Which in turn leads to the situation where it is forgotten all but completely that in fact this situation is not “normal”12. Caviglioli et al. provide an apposite quote.
Children create and revise theories in the same way that scientists create and revise theories. This idea seems to explain at least some types of cognitive development very well. We call it the theory theory. (The theory is that children have theories of the world.) … Scientists, like babies, have rich, complex, abstract, coherent representations of the world. They have theories. The theories translate the input — the evidence scientists gather — into a more abstract representation of reality.
And our “education” system sets out to ensure that as few of these babies as possible retain their theory forming and testing habit long enough to suffer the ignominy of becoming scientists (or, indeed, engineers, in any sense of the word beyond a synonym for “mechanic”). But I digress. Caglioli’s book conveniently provides a little more glue to bring the modelling thread back: it is about (and is subtitled) “visual tools for raising intelligence”. And our modelling systems (by which I mean the software constructs we develop to support the modeller in the act of modelling) should be just such “tools for raising intelligence”. This they cannot possibly be, until we take to heart that, “Programs should be written for people to read, and only incidentally for machines to execute.”
But what does this mean? For one thing, it means that most popular programming languages are totally unsuited to the task of model implementation, and this precisely because the gulf between the model itself, and the implementation of that model as a program, is so very wide. Again and again the same translations from conceptual structure, to solution scheme, to implementation in computer code are made. The results of each such effort are then encoded in such a way that similarities are forever hidden from view. Those who cannot remember the past are condemned to repeat it, but in our world the past is buried in the minds of a few individuals right from the start.
We need a language (possibly, though not necessarily, and ideally not exclusively, graphical) which allows us to express models succinctly, in a manner which enables another human being to extract the meaning of the model directly from its representation, and which simultaneously allows the computer to extract sufficient information that it can provide the simulation facility towards which so much modelling activity is directed. We also need tools which allow us to manipulate models expressed in this language interactively, and to see the impact of these manipulations on simulations directed by the expression of the model. We also need higher level tools — to be operated by humans — to support the analysis of the properties of the models we develop, but more of this below.
As soon as we say this, it becomes obvious that a language will not suffice. It seems highly improbably that the same language will allow me to express, succinctly at any rate, a model of hydrological processes and one of interacting living creatures. And this is a real problem, since creatures and hydrological processes do not occupy different worlds, and there is an increasing need to bring these two types of models, and many more, together (in order, again, to be able to advance our scientific understanding of the interactions of hydrological processes and creatures on the one hand, and to simulate the impact of possible future scenarios on those processes and creatures on the other).
So we need a set of languages, each designed to allow the expression of a certain class of models, but we also need to be able to bring together the models we express in these different languages, and this bringing together must ideally also be expressible in a language which, if not as high level as those we are using to express models, is at least high enough level that the manner — and ultimately the meaning — of the interconnection is also apparent.
It does not take a great leap of the imagination from here to see that whole hierarchies of languages, each layer building on the previous, may emerge. Groups of similar languages would have a common substrate. Common substrates may themselves have common substrates3. The more different in concept — and therefore in language style — a pair of models, the further down the language tree we would need to go in order to express their interactions.
Such a system must be capable of evolving, too. As more models are implemented, the strengths and limitations of a language will be better understood. Perhaps a language is trying to be two things, or some insight brings together two previously disparate languages. Perhaps a common pattern of interconnection emerges, and this can be converted into a new shared substrate, enabling the succinct expression of those interactions. Along with a developing understanding of models comes a developing understanding of meta-models.
This understanding of meta-models will be crucial to the development of tools which support the cognitive activities of the model developer. Tools for the analysis of the sensitivity of a model to its inputs, for example, have vastly greater utility when acting on the information to be gained from their application is easy. Models expressed as impenetrable programming language source code do not invite modification, but models expressed in a higher level language, where the structure and meaning of the model are more immediately clear would enable the application of such tools in the process of establishing truth. In an ideal future it would be possible to apply generic tools across models expressed in any of the multitude of languages envisaged, and the realisation of this relies on the existence at some level of a sufficiently generic meta-model.
By a similar token, tools for the mechanical extraction of relationships between data and complementary tools for the establishment of meaning in the relationships thus “mined” — necessary, by Abbott’s analysis, to elevate a relationship to the status of a model — should be available in any (or at least several) languages.
With tools like those described in place — even partially — the human modellers can be freed from some of the drudgery and allowed to focus on the creative act of model building, of inducing meaning. Maybe, too, the time won will allow some reflection on just how much even an apparently “true” and meaningful model allows us to say about the future. Or perhaps the handle-crankers will win out in the end.
Footnotes
1. A case in point: my father recently told me about a discussion in the magazine of the Institution of Structural Engineers (which I have yet to track down, so forgive the sketchiness and possible inaccuracy) regarding the possibility of abandoning the teaching of all methods of structural “analysis” other than the elastic method, since this is the only method which is used in “real” engineering. The fact that the elastic method requires the assembly and inversion of monstrous matrices, and provides little or no insight into structural behaviour from which the student can establish any kind of mental model, or schema, is apparently unimportant. This is the approach to “design” used in consultants offices up and down the country and round the world, so this, and only this is what must be taught in Universities. Lecturers are, after all, mere handle-crankers themselves, albeit crankers of the handle of a machine designed for the efficient production of crankers to man the handles of other, lower order, machines.
2. It might also be noted that even the “how” is dealt with inadequately; “design” courses which are based entirely around the engineering codes of practise indeed teach students “how”, but that “how” is how to find their way round the codes of practise, not how to design anything.
3. This, then, is the cause of my recent fascination with Lisp. At the bottom of this hierarchy — if we are to assume implementation on a computer — must lie machine code. But we don’t program in machine code any more, or assembly language. So why have we stopped at C and FORTRAN? Where is the next layer of language? Somehow, the servant (the computer) has become master, holding us, even in these days of wastable processor power, perilously close (and anyone who has spent days searching for memory bugs in a C program can testify how perilous it is) to the bare metal. I have yet to find a programming language which isn’t badly flawed one way or another. Smalltalk is good, almost certainly because it was designed by Lisp experts. It has more right than most languages to be adamant that its way is the right way, but when it comes to developing layered languages, this attitude is still a flaw. It remains to be seen whether Lisp is really a better compromise, or simply a different one, but a lot of discussion about the merits of Lisp focus on its support for defining appropriate languages in layers.
Comments