2
$\begingroup$

I was looking for a Dijkstra quote which I found in "On anthropomorphism in science". On re-reading it, I was struck by how, four decades later, it is so relevant to hotly debated topics. In the middle of the text, there's this paragraph:

The trouble with the metaphor is, firstly, that it invites you to identify yourself with the computational processes going on in system components and, secondly, that we see ourselves as existing in time. Consequently the use of the metaphor forces one to what we call “operational reasoning”, that is reasoning in terms of the computational processes that could take place. From a methodological point of view this is a well-identified and well-documented mistake: it induces a combinatorial explosion of the number of cases to consider and designs thus conceived are as a result full of bugs.

I'm not sure what exactly to look for here but "operational reasoning" searches give a lot about "Piaget’s Formal Operational Stage". I don't think that's what he was talking about that but I suppose it could be related.

What exactly is the "well-identified and well-documented mistake" that is referred to here? Specifically, where might I find that documentation?

$\endgroup$

1 Answer 1

2
$\begingroup$

It is likely that the term "operational" is an evolving term largely from the context of programming language and computer architecture as Dijkstra used it. For example in EWD282 (1970) one finds the use of "operational abstraction".

Traces of arguments around a dichotomy of "postulational reasoning" and "operational reasoning" can be found in numerous places of Dijkstra's writing.

In EWD463 (1974) Dijkstra engages with a quote of Russell sent to him by Hoare that states that "The advantages of the method of postulation are great; they are the same as the advantages of theft over honest toil."

By EWD604 (1977) he contrasts work Floyd's and Hoare's work on proving partial or total correctness of a program.

Floyd's approach was still very operational, and he seemed to consider the semantics of his program —as a "working mechanism"— also defined in the case of non-termination. Hoare, who only concerned himself with partial correctness, did not need to talk about termination and his approach is in that sense less operational, less "mechanical".

and later

This is a great advantage, because the question of termination or non-termination is always couched in operational terminology, from which I could now depart: if so desired I can ignore the circumstance that my text also permits the interpretation of executable code.

and finally

The above formal manipulations are not in any sense deep. But I am very pleased. Instead of building my theory upon mechanisms which may terminate or not, I built my theory on texts to which —but I don't need to remember that— terminating mechanisms can be made to correspond.

In some sense Dijkstra feels liberated from considering the actual underlying mechanics/operations of the system and thinks in an abstract formal system, that instead, "can be made to correspond" to a mechanism.

EWD936 as mentioned in the question is followed by more writing by Dijkstra on fleshing out his notion of "operational/postulational reasoning" see also EWD 1012, where the use and praise of "postulational" is referred to E.T. Bell (1940), which likely is the first edition of "The development of mathematics". I do not have access to this edition. However we indeed find that Bell discusses the axiomatization of the early 20th century as postulational method in the second edition.

And it is also contained in his rather controversial EWD 1036. For Dijkstra his view was well grounded on having understood past mistakes. I suspect that his comments regarding "well-identified and well-documented mistake" may well be correctly understood in this sense. The particular type of "postulational" thinking and consequent attitudes towards logic and abstraction in CS teaching that Dijkstra advocated was by no means uncontroversial in the field.

$\endgroup$
3
  • $\begingroup$ @JimmyJames Fixed. Thanks! $\endgroup$ Commented Aug 27 at 15:25
  • $\begingroup$ A very well documented answer. I find Dijkstra's writing very readable which I think might make me feel that I understand it better than I do. In a really oversimplified nutshell, he's basically arguing for a bottom-up language design from axioms (maybe like Haskell) versus a top-down design from capabilities (e.g. COBOL). Am I anywhere close? $\endgroup$ Commented Aug 28 at 15:54
  • $\begingroup$ @JimmyJames Roughly. To me Dijkstra's position actually evolves somewhat, in the end he rejects reference to anthropomorphic metaphors completely while early on he was very close to operational concerns. In a sense he is moving more and more into the abstract, axiomatic, from the concrete, operational, intuitive. $\endgroup$ Commented Aug 28 at 16:23

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.