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,
href="http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/">course
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.
Gopnik,
Meltzoff and Kuhl, “How Babies Think”
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.
![[amazon]](http://www.effhotel.org.uk/people/hamish/images/icons/amzn-y12.png){kind=icon}
Recent Comments