Dijkstra's Rallying Cry for Generalization - diary70s
http://www.dijkstrascry.com/taxonomy/term/9
My diary on what Dijkstra did in the 1970s.
enMachine Oriented Higher Level Languages
http://www.dijkstrascry.com/node/121
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">August 1973</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>Something significant happened during the 1950s in the history of science & technology. By 1950, logicians and linguists had been studying “artificial languages” and “natural languages” for centuries. But, the words “programming language” were not used at all. By 1959, however, those words had become common currency. And, in today's digital world, the absence of “programming languages” is totally unthinkable.</p>
<p>In this post I will discuss the 1973 conference <em>Machine Oriented Higher Level Languages. </em>I will clarify what those words meant (to the conference attendees) in relation to a "higher level" programming language and in relation to a computing machine.</p>
<p>As I argue in my recent article, the advent of “programming languages” came during the 1950s; i.e., during a decade of cross fertilization between logic, linguistics, and computing [1]. John W. Carr played an important role here. By the mid-to-late 1960s, overarching technological concepts had matured and a science was born. Examples of such concepts are: a universal Turing machine, the pushdown store, and undecidability. See also my discussion with Donald Knuth [2].</p>
<p>During the 1960s, the concepts of “language” and “machine” became increasingly interchangeable. By the end of that decade, many programmers viewed the workings of a program “by virtue of a whole hierarchy of abstract machines extending down to the hardware machine” (cf. Koster in 1973 [3, p.117]).</p>
<p>Also during the 1960s, an increasing number of researchers began to view a programming language as a means to communicate between people [3, p.109]. Researchers like Carr and Dijkstra had already been doing that for years. Others, including Ichbiah, Koster, Horning, van der Poel, Wirth, and Wulf, were more hesitant. They too appreciated the virtues of “gaining expressive power” by designing a “higher level” language. But, they were also worried about the price of “losing control over how the algorithm is carried out” (cf. [3, p.359]).</p>
<p>Ichbiah et. al. attended the 1973 conference Machine Oriented Higher Level Languages in Trondheim, Norway to clarify the difference between “high-level languages” on the one hand and “system languages” and “MOLs” (“Machine-Oriented Languages”) on the other hand [3]. It was the latter two languages that concerned them the most.</p>
<p>One of the participants at the conference connected a “programming language” with “generality”. A programming language that is too specific, he said, is more a “notation” than a true language (cf. [3, p.113]). In other words, being too specific or too close to the bare machine was no good. The participants favored “language” and “generality” for the same reasons that Carr and Dijkstra did. Portability, for example, was easier to obtain with a “machine-independent” program that was expressed in a “language” [3, p.110].</p>
<p>But, abstracting from too many machine details was also problematic. Ichbiah et. al. wanted to program systems — later called real-time, embedded systems. Doing that meant eschewing language features “whose translation involves uncontrollable run-time mechanisms”. A “space manager” (garbage collector), for example, was problematic in a system language because it typically incurred run-time requests that were difficult to predict at compile time (cf. Ichbiah's remarks [3, p.110]).</p>
<p>Portability of software (cf. generalisation) versus machine efficiency (cf. specialisation) — that was the dichotomy of the conference. On the one hand, a Machine-Oriented Language “may not be very much higher level than an assembly language” [3, p.118]. Because, “to utilize a given machine up to its maximum efficiency, you must tailor the language to it” [3, p. 122]. Programmers needed to get at the machine. As a participant complained, “I cannot do that if the guys give me lots of language which gets between me and it” [3, p.403]. On the other hand, with a machine oriented language which “is designed to be portable”, it is possible to choose between “polish[ing] for a particular machine” and “retain[ing] the ability to port at lessened efficiency” [3, p.115].</p>
<p>Willem van der Poel actively participated in the 1973 conference and edited its proceedings. In contrast to Dijkstra, who wanted to abstract from mechanistic reasoning of program behavior, van der Poel said that “we must learn to think more mechanically and not always think that the machine can do everything, which we have in our minds” [3, p.401]. Also in contrast to Dijkstra who was fully occupied with proving the correctness of programs, van der Poel emphasized that most errors are made “in mapping our thoughts on paper” [3, p.413] and that “there is no way to prove that [this] first step is correct” [3, p.402] — this is what Dijkstra later called “the Pleasantness Problem” and which I have discussed with Peter Naur [4] and Michael A. Jackson [5]. According to van der Poel, “There is no wrong program, it is simply another program” [3, p.4].</p>
<p>Dijkstra and van der Poel did share one point of view. Both men did not want to abstract from the finiteness of machines and programs, even when reasoning abstractly about software. <a href="/infinite">Dijkstra did this in the context of axiom-based semantics</a>. Van der Poel did this in the context of system languages and machine oriented languages. At the conference in Trondheim, van der Poel said:</p>
<blockquote><p>We like to talk about things as sets and integers and real numbers. But often we do not realize that within a machine, there are no real numbers. It is only a subset of them [...] There are no integers either; machine integers do not fulfill the axioms of Peano, that for every integer, there is a successor. [3, p.401] [See also p.411 for a similar comment.]</p>
</blockquote>
<p>Van der Poel and the other system programmers at the Trondheim conference were positioning themselves in between the generalists (à la Carr, Dijkstra, van Wijngaarden) and the very many specialists from industry who were “still” programming in assembly language. The concern of Ichbiah, van der Poel, et. al. was “system programming”, as opposed to defining — solely on paper — a so-called elegant programming language à la ALGOL 68. Their appreciation for hierarchical program design (cf. Dijkstra's THE system) was real, as the following words by Horning partly illustrate. But their “mini-computers” were real too [3, p.8] and those were programmed in assembly.</p>
<p>In Horning's words:</p>
<blockquote><p>[T]he basic concepts of system programming are not very different from some sub-set of the basic concepts of programming in general. Another thing which high-level languages do is that they remove certain flexibilities from the programmer. They specialize the machine, so that certain mistakes become impossible. [3, p.110]</p>
</blockquote>
<p>These comments align well with the remark made by Liskov in a 2010 interview:</p>
<blockquote><p>[W]henever you provide a higher level language, you take away the features of the underlying machine, because you replace that machine with a higher level and you're supposed to use the machine only through that higher level. And they were worried that the loss of expressiveness from the lower level to the higher level might be a serious problem. And, it is a problem if you think about writing low-level systems in Java today; you do sometimes dip down into C in order to accomplish a few things very efficiently. But, in general, by now we understand that you can write programs in any universal programming language. [6, p.142]</p>
</blockquote>
<p>Liskov's “we now understand” in the last sentence suggests that deep, practical, implications of Turing's 1936 universal machine took time to become common knowledge. (Moreover, many computer practitioners acquired that knowledge without relying on modern logic.) I have argued that few men (Burks, Carr, Gorn, and Perlis) already began to see such connections between theory and practice in the 1950s [1].</p>
<p><strong>Bibliography</strong></p>
<p>[1] E.G. Daylight. <a href="/TuringPaper">Towards a Historical Notion of "Turing — the Father of Computer Science"</a>. History and Philosophy of Logic. To appear. I thank Tom Haigh and other reviewers for commenting on multiple drafts of this article, starting in February 2013.</p>
<p>[2] D.E. Knuth, E.G. Daylight. <em><a href="http://www.lonelyscholar.com/Knuth">The Essential Knuth</a></em>. Lonely Scholar, August 2013.</p>
<p>[3] W.L. van der Poel and L.A. Maarssen, editors. <em>Machine Oriented Higher Level Languages (MOHL), </em>IFIP Working Conference on MOHL, Trondheim (Norway), 1973.</p>
<p>[4] E.G. Daylight. <a href="http://www.lonelyscholar.com/node/7"><em>Pluralism in Software Engineering: Turing Award Winner Peter Naur Explains.</em></a> Lonely Scholar, 2011.</p>
<p>[5] A forthcoming interview with Michael A. Jackson.</p>
<p>[6] E.G. Daylight. <a href="http://www.lonelyscholar.com/dawn"><em>The Dawn of Software Engineering: from Turing to Dijkstra</em>.</a> Lonely Scholar, 2012.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Tue, 05 Nov 2013 08:22:13 +0000egdaylight121 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/121#commentsGeneva Talk
http://www.dijkstrascry.com/node/112
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">1973</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>[Here are the contents of some visuals from Dijkstra's presentation in Geneva, 1973. Source: my archives, Box 11]</p>
<p><strong>(1A)</strong> <br />Our programs serve to instruct our machines. <br />--> A “mismatch” is blamed on the program.</p>
<p><strong>(1B)</strong><br />Our machines serve to execute our programs.<br />--> A “mismatch” is blamed on the machine.</p>
<p><strong>(5)</strong><br />When a <span style="text-decoration: underline;">whole</span> is considered as composed out of parts, the <span style="text-decoration: underline;">composition</span> must define how the <span style="text-decoration: underline;">properties of the whole</span> follow from the <span style="text-decoration: underline;">properties of the parts</span>.<br />We therefore restrict ourselves to those ways of composing for which the above functional dependance is mathematically well-manageable.</p>
<p><strong>(6)</strong> <br />We maintain a strict separation between “what something does” — its external properties — and “how something works” — its internal construction — .<br />{bottle full or drunk} empty the whisky bottle {drunk}<br />The initial condition “bottle full or drunk” guarantees that the action “empty the whisky bottle” cannot take place without causing the final state “drunk”.</p>
<p><strong>(11)</strong><br />In order to be convincing a proof must be reasonably short and straightforward.<br /><span style="text-decoration: underline;">shortness</span> is achieved by the introduction of (suitable) “abstract data types” and “abstract operations”<br /><span style="text-decoration: underline;">straightforwardness</span> is achieved by sticking to “sequencing disciplines” for which powerful theorems are known.</p>
<p><strong>(12)</strong><br />A <span style="text-decoration: underline;">concrete</span> programming language can be translated automatically — i.e. without further human intervention — into (reasonably) efficiently executable code.<br />For an <span style="text-decoration: underline;">abstract</span> programming language the translation is allowed to require further human assistance.<br />Abstract programs are indispensable stepping stones!</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Tue, 30 Apr 2013 06:13:34 +0000egdaylight112 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/112#commentsStrachey vs. Dijkstra :: Infinite vs. Finite
http://www.dijkstrascry.com/infinite
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">Spring 1973</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>In 1962 Christopher Strachey reasoned about ALGOL60 programs in terms of machine efficiency and, hence, to a non negligible extent he worked <a href="/node/4"><em>from </em>the machine <em>to </em>the language. Dijkstra, by contrast,</a> insisted on reasoning from ALGOL60 to the machine. In Strachey's words:</p>
<blockquote><p>I think the question of simplifying or reducing a language in order to make the object program more efficient is extremely important. I disagree fundamentally with Dijkstra, about the necessity of having everything as general as possible in all possible occasions as I think that this is a purely theoretical approach […] [1, p.368] [2, Ch.3]</p>
</blockquote>
<p>In 1973, Strachey insisted on abstracting away from the finiteness of real computers when reasoning about ALGOL60 programs. First ensure program correctness in an exact mathematical setting, he said, before descending to the level of bit patterns inside the finite machine. A high level programming language such as ALGOL60</p>
<blockquote><p>allows us to think about mathematical objects, such as integers, instead of their rather arbitrary representation by bit-patterns inside the machine. [3, p.2]</p>
</blockquote>
<p>The luxury of a high level language, Strachey continued, was that it allowed the programmer to reason about <em>variables</em> instead of <em>locations</em> (or <em>addresses</em>) and <em>functions</em> instead of <em>subroutines</em>. When an ALGOL60 programmer writes a statement such as <strong>x := Sin(y+3)</strong> then he has in mind the mathematical <em>functions</em> sine and addition.</p>
<p>For Strachey, the finiteness of the machine only entered the picture afterwards.</p>
<blockquote><p>It is true that our machines can only provide an <em>approximation</em> to these functions but the discrepancies are generally small and we usually start by ignoring them. It is only after we have devised a program which would be correct if the functions used were the exact mathematical ones that we can start investigating the errors caused by the finite nature of our computer. [3, p.2, original italics]</p>
</blockquote>
<p>In his paper, which was in large part due to his work with Dana Scott, Strachey assigned “the usual mathematical” properties to his domains: Booleans <em>T</em>, Integers <em>N</em>, Reals <em>R</em>, etc. Likewise, he defined stored values <em>V</em> as <em>T+N+R</em> and, hence, allowed them to be arbitrarily large. For example, the infinitely long number Pi belongs to <em>R</em>. He then formalized ALGOL60 in terms of these arbitrarily large domains — for example, he defined vectors as <em>L* </em> = <em>L + L<sup>2</sup> + L<sup>3</sup> + ...</em> where <em>L</em> denotes the domain of locations — and, hence, appropriated ALGOL60 in this infinite setting [3, p.5,16,17]. Contrast this appropriation with Peter Naur's original intention of ALGOL60 and van Wijngaarden's formalization [4] in which the arithmetic of real numbers in ALGOL60 was explicitly defined for a finite setting:</p>
<blockquote><p><strong>Arithmetic of real quantities.</strong> Numbers and variables of type real must be interpreted in the sense of numerical analysis, i.e. as entities defined inherently with only a finite accuracy. Similarly, the possibility of the occurrence of a finite deviation from the mathematically defined result in any arithmetic expression is explicitly understood. No exact arithmetic will be specified, however, and it is indeed understood that different hardware representations may evaluate arithmetic expressions differently. The control of the possible consequences of such differences must be carried out by the methods of numerical analysis. This control must be considered a part of the process to be described, and will therefore be expressed in terms of the language itself.” [4] [5]</p>
</blockquote>
<p>Strachey subsequently used his formalism to compare and contrast a variety of programming languages, including ALGOL60. But, note thus that this was all happening under the umbrella of exact mathematics and, hence, in an arbitrarily large and potentially infinite setting. The finiteness was intentionally ignored.</p>
<p>In 1973 Dijkstra was, not unlike Naur and van Wijngaarden in the 1960s, viewing real arithmetic and programming languages in a finite setting. He did not want to follow Strachey and Scott in abstracting away from the finiteness. In Dijkstra's words:</p>
<blockquote><p>We are considering finite computations only; therefore we can restrict ourselves to computational processes taking place in a finite state machine — although the possible number of states may be very, very large — and take the point of view that the net effect of the computation can be described by the transition from initial to final state. [EWD 367, p.0] [EWD 372, p.1]</p>
</blockquote>
<p>The previous passage appears in both Dijkstra's draft and final texts: <a href="http://www.cs.utexas.edu/users/EWD/index03xx.html">EWD 367</a> and <a href="http://www.cs.utexas.edu/users/EWD/index03xx.html">EWD 372</a>. But the latter also contains a critical remark for those who ignored the finiteness of programming problems. Note that Dijkstra attributed the infiniteness to Turing and Scott; that is, to mathematical logic in general.</p>
<blockquote><p>(Since the classical work of A.M. <strong>Turing</strong>, and again since the recent work of D. <strong>Scott</strong>, one often encounters the tacid [sic] assumption that size and speed of today's computers are so huge, that the inclusion of infinite computations leads to the most appropriate model. I would be willing to buy that if — as in the case of “the line at infinity”, sweetly leading to projective geometry — the suggested generalization would clean up the majority of the arguments. Thanks to Cantor, Dedekind et al., however, we know that the inclusion of the infinite computation is not a logically painless affair, on the contrary! In the light of that experience it seems more effective to restrict oneself to finite computations taking place in a finite, but sufficiently large universe, thereby avoiding a number of otherwise self-inflicting pains. Those mathematicians that are so biased as to refuse to consider an area of thought worthy of their attention, unless it pays full attention to their pet generalizations, should perhaps not try to follow the rest of my argument.) [EWD 372, p.1, my bold]</p>
</blockquote>
<p>On the one hand, Dijkstra, Parnas, and others frequently insisted throughout their careers not to ignore the finiteness of real machinery, even when reasoning abstractly about software [6]. On the other hand, contrast the above passage with <a href="/node/46">my post on the older Dijkstra in 1981</a> when he did exploit the infinite albeit for his work on mathematical methodology, not programming methodology.</p>
<p>During the 1970s, Dijkstra became increasingly interested in Hoare's axiomatic-based reasoning. Intuition, so dominant in his metaphors and analogies of the 1950s and 1960s, was making place for purely formal reasoning.</p>
<blockquote><p>I apologize most sincerely for the last few pages of formal labour, which took me a few days to write down, while a greater expert in the propositional calculus probably could have done it much more efficiently. It is by now most urgent that we relate the above to our intuitive understanding of the recursive procedure: then all our formulae become quite obvious (and the painfulness of my formal proofs becomes frustrating!) [EWD367, p.10]</p>
</blockquote>
<p><strong>References</strong></p>
<p>[1] Panel Discussion: <em>`Efficient Processor Construction'</em>. Proceedings of the International Symposium of Symbolic Languages in Data Processing. C.M. Popplewell (ed.) March 1962.</p>
<p>[2] E.G. Daylight, <a href="http://www.dijkstrascry.com/dawn"><em>The Dawn of Software Engineering: from Turing to Dijkstra</em></a>, Lonely Scholar (2012).</p>
<p>[3] C. Strachey, `The Varieties of Programming Language', Technical Monograph PRG-10, Oxford University Computing Laboratory, March, 1973. The monograph is a revised and slightly expanded version of a paper given at the International Computing Symposium at Venice 12-14 April, 1972.</p>
<p>[4] J.W. Backus et al., P. Naur (ed.), `Report on the algorithmic language ALGOL 60'. <em>CACM</em> 3.5, p. 299-314, 1960.</p>
<p>[5] A. van Wijngaarden, `Numerical analysis as an independent science', <span style="font-style: italic;">BIT</span> 6, p. 66-81, 1966.</p>
<p>[EWD 367] E.W. Dijkstra, `<a href="http://www.cs.utexas.edu/users/EWD/index03xx.html">EWD 367: On the axiomatic definition of semantics</a>', 29 April 1973.</p>
<p>[EWD 372] E.W. Dijkstra, `<a href="http://www.cs.utexas.edu/users/EWD/index03xx.html">EWD 372: A simple axiomatic basis for programming language constructs</a>', 8 May 1973.</p>
<p>[6] E.G. Daylight, `Towards a Historical Notion of "Turing — the Father of Computer Science"'. Submitted to a special issue in the journal <em>History and Philosophy of Logic</em>.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Fri, 29 Mar 2013 19:44:27 +0000egdaylight111 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/infinite#commentsThings Dijkstra would like to do
http://www.dijkstrascry.com/node/110
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">18 January 1973</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>[The following words, written by Dijkstra in January 1973, are from Box 9 in my archive.]</p>
<p>Things I would like to do (they are not all unrelated).</p>
<p>1) write a book on the art of programming.</p>
<p>2) find a good notation for doing justice to representational abstraction.</p>
<p>3) investigate axiomatic definition of semantics with the aim of</p>
<p style="padding-left: 30px;">3a) giving a sound mathematical basis for “intuitive theorems”.<br />3b) shaping the theorems and/or axioms into a constructive tool for program composition.<br />3c) doing the same for multi-program composition.</p>
<p>4) to continue my study about the techniques for fighting “spaghetti” with particular reference to</p>
<p style="padding-left: 30px;">4a) the logical aspects of it — “how to make the program modules correspond to the proof modules”<br />4b) the quantative aspects of it, such as “identifies explosion”<br />4c) the flexibility aspect, i.e. mapping programs on each other.<br />4d) robustness, in particular physical compactification of the basss [sic] of basic assertions.</p>
<p>5) to develop the necessary mathematics to control behaviour and design of systems with asynchronous components and distributed control, such that</p>
<p style="padding-left: 30px;">5a) local behaviour be “independent of” total configuration specification<br />5b) the system be “self-stabilizing”.<br />5c) successful stabilization can be detected.</p>
<p>6) to transmit my fears with regard to LSI-quality control.</p>
<p> 6a) with regard to the design<br /> 6b) with regard to the necessary quality control regarding individual instances.<br /> (This is a clear case of research that I cannot do “all by myself”. It ties with my notions about “robustness”.)</p>
<p>7) continue to think about and hopefully isolate the current hardware characteristics that exert such a strong pressure to make spaghetti and then find out, whether such features could be avoided.</p>
<p> </p>
<p>All this I regard as work that must be done in free interchange with the outer world. The book, for instance, should be published via the normal channels: I do not hesitate to suggest this as B's market should profit more than anyone else's [sic] from a better understanding of programming. </p>
<p>The attitude towards my work is that it should be fit for publication and I expect to continue to submit at regular intervals articles to scientific journals. Also this I regard in B's interest: if I have the function of “flag” as well, I should not fade!</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Mon, 18 Mar 2013 14:54:31 +0000egdaylight110 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/110#commentsDijkstra's "Software Engineer" in 1972
http://www.dijkstrascry.com/node/104
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">October 1972</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>John C. Reynolds wrote to me:</p>
<blockquote><p>As Dijkstra was fond of pointing out, the community of people who call themselves “software engineers” is marred nowadays by an abundance of second rate work — so much so that others have come to disdain the term and call themselves “computer scientists”. But in the 60’s and 70’s, people such as Hoare, Wirth, and Dijkstra proudly and properly called themselves software engineers, and managed to be simultaneously rigorous and useful.</p>
</blockquote>
<p>The previous passage is part of Reynolds's comments on my book <em>The Dawn of Software Engineering: from Turing to Dijkstra</em> [1]. Reynolds's recollections are supported by Dijkstra's Dutch texts <a href="http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD349.PDF">EWD 349</a> and <a href="http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD353.PDF">EWD 353</a>, both written in 1972, in which he used the English words "software engineer". For example, Dijkstra wrote:</p>
<blockquote><p>We, professors in Eindhoven, have discussed the curriculum of mathematical engineering at length. We have come up with a list of courses for those students who want to become software engineers. [Paraphrased translation from <a href="http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD353.PDF">EWD 353</a>, p.0]</p>
</blockquote>
<p>Dijkstra continued by enumerating eight mandatory courses, including:</p>
<ul><li><strong>Introduction to the Art of Programming</strong> (i.e. Dijkstra's course on programming methodology with a strong emphasis on program correctness)</li>
<li><strong>Applied Logic</strong> (i.e. automata theory)</li>
<li><strong>Syntactic Techniques</strong> (i.e. parsing, type checking)</li>
<li><strong>Axiomatisation of Semantics</strong> (cf. Hoare's 1969 paper [2])</li>
</ul><p>The four courses listed above are very mathematical in nature. Turing's and Post's influence were especially felt in the Applied Logic course, as Dijkstra alluded to in [<a href="http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD349.PDF">EWD 349</a>, p.3]. Applied Logic served the purpose of teaching formal techniques of standing; that is, techniques that gave software engineering a more solid basis. These techniques included formal systems and (un)decidability questions. Dijkstra explicitly mentioned generative grammars, the ambiguity problem, and Chomsky and Church. In the brand new course on Axiomatisation of Semantics, students would formalize some of the results that Dijkstra had intuitively derived in his programming methodology course. Dijkstra emphasized that axiomatically defining the semantics of a programming language was a new research topic.</p>
<p>Unsurprisingly, however, not every Dutch academic shared Dijkstra's views on a curriculum for “Informatica” — a term which, given the context, I am tempted to translate to “software engineering”. According to Dijkstra, many of his critics were unaware of the existence of the foundations of “Informatica”. His critics did not see that each computer program shares an application-independent and theoretical foundation. This unawareness, in turn, explains why his critics wanted to disperse the “Informatica” courses over various university departments, instead of create an independent “Informatica” curriculum [<a href="http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD349.PDF">EWD 349</a>, p.0].</p>
<p>Dijkstra's observation in 1972 supports the claim made in my book [1] that many computer professionals in the 1950s and 1960s were unaware of the theoretical work of Turing (and, similarly, of Post's and Church's work). Today, Turing is proclaimed by many to be the “father of computer science”, but this was a far less common view in 1972 and even though seven Turing Awards had already been handed out.</p>
<p>[1] E.G. Daylight, <a href="http://www.dijkstrascry.com/dawn"><em>The Dawn of Software Engineering: from Turing to Dijkstra</em></a>, Lonely Scholar (2012).</p>
<p>[2] C.A.R. Hoare, <span class="title">An Axiomatic Basis for Computer Programming.</span> Commun. ACM 12 (10): 576-580 (1969).</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Wed, 05 Dec 2012 18:14:49 +0000egdaylight104 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/104#commentsStep-Wise Composition: Confusing Terminology?
http://www.dijkstrascry.com/node/98
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">June 1972</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>To clarify his step-wise program composition, Dijkstra used terms like “program layers” and “levels of abstraction” in his `Notes on Structured Programming' [1, Chapter 1]. These terms were not well defined as Dijkstra conceded later. As a result, Dijkstra's exposition — although extremely rich in content — was difficult to understand completely. See e.g. Denning's clarifying article on Structured Programming [3] or my interview with Liskov who mentions Parnas in this regard [2].</p>
<p>In <a href="/node/97">my previous post I re-introduced some of Dijkstra's descriptions of his prime-number example</a>. The first two, Description 0 and Description 1, are presented again below.</p>
<p><strong>Description 0:</strong><br /><strong>begin</strong> “print first thousand prime numbers”<strong> end</strong></p>
<p><strong>Description 1:</strong><br /><strong>begin</strong> variable “table p”;<br /> “fill table p with first thousand prime numbers”;<br /> “print table p”<strong> end</strong></p>
<p>Dijkstra used several terms to denote the same thing. The word “description”, for instance, was used as a synonym for “program layer”. Description 0 is thus Program Layer 0 and Description 1 is Program Layer 1.</p>
<p>Each line below is a list of synonyms:</p>
<ul><li>“refinements” — “decompositions” </li>
<li>“description” — “program layer” — “level of abstraction” </li>
<li>“abstract program” — “virtual machine” </li>
</ul><p>Only the very last description obtained by step-wise composition corresponds to the final executable program. All other descriptions, such as Description 0 and Description 1, are abstract programs. Hence, for these abstract cases, the following terms can be used as synonyms as well:</p>
<ul><li>“description” — “program layer” — “level of abstraction” — “abstract program” — “virtual machine”</li>
</ul><p>Dijkstra also distinguished a more concrete program from an abstract program by means of the words “children” and “ancestor”. The latter word occurs in the following passage:</p>
<blockquote><p>when a program has been built up to an intermediate stage of refinement, what has then been written down is in fact a suitable “common ancestor” for all possible programs produced by further refinements. [1,p.40]</p>
</blockquote>
<p>More interesting is Dijkstra's usage of the words “program layer” in the following quote:</p>
<blockquote><p>If we succeed in building up our program along the lines just given, we have arranged our program in layers. Each program layer is to be understood all by itself, under the assumption of a suitable machine to execute it, while the function of each layer is to simulate the machine that is assumed to be available on the level immediately above it. [1,p.49]</p>
</blockquote>
<p>The resemblance with Dijkstra's THE system is apparent because <a href="/node/67">THE is essentially a layered system of abstract machines</a>. Note, however, that the layers constituting the THE system are part of the end product, while the program layers in a step-wise program composition do <em>not </em>constitute the final program. In a step-wise program composition, only the very last program layer is expressed in executable code and it <em>is</em> the final program.</p>
<p>Having said that, I hasten to remark that the complete step-wise program composition <em>is</em> reflected in the final program <em>structure</em>. That is, the series of decision choices that the programmer makes is reflected in the structure of his final executable program. Description 1, presented above, already resembles much of the structure of the final description; that is, of the final executable program. Description 2, presented in <a href="/node/97">my previous post</a>, resembles more structure of the final description. Description 3 is even closer to the final executable program, and so on.</p>
<p>As the previous and also the following passage illustrate, Dijkstra associated a “program layer” with a “machine”.</p>
<blockquote><p>All the time I design programs for non-existing machines and add: “if we now had a machine comprising the primitives here assumed, then the job is done”. [...] Again we are left with a primitive that admits further refinement without commitments regarding the other primitives. [...] we create the machine [...] [1,p.55]</p>
</blockquote>
<p>Here we again see Dijkstra continue with what he had started to do in Amsterdam during the 1950s: programming non-existing machines on paper. (See <a href="/node/94">my previous post</a> for some preliminary comments on Dijkstra's work during the early 1950s.)</p>
<p>Dijkstra's hierarchy of machines also shows some resemblance to Van Wijngaarden's 1962 work on `Generalized Algol' [4]. <a href="/node/25">Dijkstra and Van Wijngaarden had been working and thinking alike in Amsterdam during the 1950s</a>.</p>
<p><strong>A Bit Confusing</strong></p>
<p>Unfortunately, Dijkstra's excessive use of synonyms made his exposition a bit confusing. Consider, for instance, the following list of words used by Dijkstra:<strong><br /></strong></p>
<ol><li>“layered hierarchy of machines”</li>
<li>“a layer contains “a bunch of programs” to be executed by some conceptual machine”</li>
<li>“a picture of program structure as a layered hierarchy of machines” [1, p.50]</li>
</ol><p>The words in the first line refer, for instance, to the descriptions in the prime-number example: Description 0 — Description 1 — Description 2. Each description corresponds to a machine. The “layer” in the second line refers to a specific description, such as Description 1. So far so good. But the words in the third line are confusing: “program structure” here refers, again, to the layered descriptions in the prime-number example and <em>not </em>to the structure of the final executable program. Dijkstra's “program” refers to all descriptions together, not solely to the final executable program.</p>
<p>Dijkstra also used the words “levels of abstraction” in an attempt to get his intuitive ideas across.</p>
<blockquote><p>Our experience [...] strongly suggests that the arrangement of various layers, corresponding to different levels of abstraction, is an attractive vehicle for program composition. [...] It is not vain to hope that many a program modification can now be presented as replacement of one (virtual) machine by a compatible one. [1, p.49]</p>
</blockquote>
<p>Strictly speaking, the words “virtual machine” in this context refer to a step (i.e. a program layer) in a step-wise program composition, not to a structural entity of the final program such as a layer in the THE system. Having said that, recall that the step-wise composition and the structure of the final program are closely related. It is no coincidence that the THE system itself can easily be modified (by changing one of its layers) because its layered structure reflects the decision choices that were (supposedly) made during its step-wise creation.</p>
<p> </p>
<p>[1] O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. <em>Structured Programming</em>. Academic Press, London - New York - San Francisco, 1972.</p>
<p>[2] E.G. Daylight. <a href="http://www.lonelyscholar.com/dawn"><em>The Dawn of Software Engineering: from Turing to Dijkstra</em></a>. Lonely Scholar, April 2012.</p>
<p>[3] P.J. Denning. A hard look at structured programming. In <em>Structured Programming: Analysis</em>, p. 183-202. Infotech State of the Art Report, Maidenhead, England, 1976.</p>
<p>[4] A. van Wijngaarden. Generalized ALGOL. In R. Goodman, editor, Annual Review Automatic Programming, volume 3, p. 17-26. Pergamon Press, 1963.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Fri, 07 Sep 2012 15:12:11 +0000egdaylight98 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/98#commentsStep-Wise Composition: Generality Prevails
http://www.dijkstrascry.com/node/97
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">June 1972</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>In his 1972 `Notes on Structured Programming' [1, Chapter 1], Dijkstra introduced a methodology called step-wise program composition. He explained how to compose a program in minute steps, deciding each time as little as possible so that the correctness of each step is obvious.</p>
<p>Dijkstra applied his step-wise program composition on multiple problems in his `Notes on Structured Programming'. One problem was to instruct a computer to print a table of the first 1000 prime numbers. Dijkstra's step-wise composition of this problem into imperative code has also been investigated <a href="http://vanemden.wordpress.com/2011/01/15/another-scoop-by-dijkstra/#more-366">by Maarten van Emden on his blog</a>. Another problem was, roughly stated, to let a computer print an image on paper.</p>
<p>Each step in Dijkstra's step-wise composition corresponds to a decision choice. General decision choices are made first, followed by more problem specific choices.</p>
<blockquote><p>[W]ith progressing refinement, more detail about the actual problem statement has been brought into the picture. [...] As a result, our first levels of refinement are equally applicable for the members of a whole class of problem statements. [1,p.41]</p>
</blockquote>
<p>For the problem of computing prime numbers, Dijkstra only used nontrivial arithmetical facts about prime numbers at a relatively late stage in his step-wise composition. Likewise, for his printing problem where an image is made up of lines, Dijkstra first solely reasoned about the image as a holistic entity. Only at a later stage did he “explain away” the image in terms of lines. He subsequently <em>only </em>reasoned in terms of lines, irrespective of whether the lines constituted an image or not.</p>
<p>Zooming in on Dijkstra's prime-number example, here are the first three successive — and increasingly detailed — descriptions which lead towards an imperative program that is executable on a computer.</p>
<p><strong>Description 0:</strong><br /><strong>begin</strong> “print first thousand prime numbers”<strong> end</strong></p>
<p><strong>Description 1:</strong><br /><strong>begin</strong> variable “table p”;<br /> “fill table p with first thousand prime numbers”;<br /> “print table p”<strong> end</strong></p>
<p><strong>Description 2:<br />begin </strong>“integer array p[1:1000]”;<br />“make for k from 1 through 1000 p[k] equal to the kth prime number”<br />“print p[k] for k from 1 through 1000”<strong> end<br /></strong></p>
<p>The previous descriptions help to clarify some of Dijkstra's terminology. Each line in Description 2 is, in this particular example, a <em>refinement </em>of the corresponding line in Description 1. Description 2 thus contains three refinements: the first one describes a <em>resource</em>, while the other two describe <em>actions</em>. Line 1 in Description 2 declares the resource <strong>array </strong>as a refinement of the <em>abstract </em>resource “table p” in Description 1. Likewise, Line 2 in Description 2 is a refinement of the more abstract action “fill table p with first thousand prime numbers” in Description 1.</p>
<p>Dijkstra subsequently refined both actions in Description 2 independently of each other (leading to Description 3, not shown above). The reason why Dijkstra was able to refine both actions independently was because of his insistence to generalize as much as possible: the printing action is applicable in several contexts, not solely in the specific context of printing prime numbers.</p>
<p>Generalization thus prevailed, once again, in Dijkstra's thinking. This led him to consider a whole <em>program family</em>. Description 0, for instance, captures a family of programs, each of which prints the same numbers onto some medium. In Dijkstra's words:</p>
<blockquote><p>[I]t is a very worth-while exercise to look for feasible generalisations of conceivable utility, because such considerations may give clear guidance as to how the final program should be structured. But such considerations boil down to ... conceiving (more or less explicitly) a whole program family! [1,p.41]</p>
</blockquote>
<p> </p>
<p>[1] O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. <em>Structured Programming</em>. Academic Press, London - New York - San Francisco, 1972.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Thu, 02 Aug 2012 14:49:55 +0000egdaylight97 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/97#commentsMathematics and reasoning by analogy
http://www.dijkstrascry.com/node/96
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">June 1972</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>Although he was a theoretical physicist by education, Dijkstra had been exposed to his mother's mathematical thinking during most of his teens. This observation helps explain why he continued to seek general mathematical arguments in his 1972 `Notes on Structured Programming' [2, Chapter 1].</p>
<p><a href="/node/75">We have already seen that in 1961 Dijkstra explained why it is important to have a small number of general language constructs.</a> A decade later, in his `Notes on Structured Programming', Dijkstra put emphasis on “the effort to establish a few, well-chosen sequencing constructs in programming”. Examples of sequencing constructs are:</p>
<ul><li>concatenation (;)</li>
<li>selection (<em>if</em> ... <em>then</em> ... <em>else</em> ...)</li>
<li>repetition (<em>while</em> ... <em>do</em> ...).</li>
</ul><p>According to Dijkstra, a theorem for which several pages full of conditions have to be satisfied is not a convenient tool to use, “as all conditions have to be verified whenever the theorem is appealed to”. Generality reflected by a small number of conditions is a necessary requirement for practical applicability. Dijkstra used Pythagoras's Theorem in one of his many attempts to get this point across.</p>
<blockquote><p>In Euclidean geometry, Pythagoras' Theorem holds for any three points A, B, and C such that through A and C a straight line can be drawn orthogonal to a straight line through B and C. How many mathematicians appreciate that the theorem remains applicable when some or all of the points A, B, and C coincide? Yet this seems largely responsible for the convenience with which Pythagoras' Theorem can be used. [2, p.3]</p>
</blockquote>
<p>Avoiding case distinctions leads to an increase in clarity and “clarity has pronounced quantitative aspects, a fact many mathematicians, curiously enough, seem to be unaware of”. The many mathematicians were mostly close colleagues of Dijkstra in Eindhoven, colleagues with PhDs in mathematics. Dijkstra made clear, as he did in many of his writings, that he was <em>not</em> one of them.</p>
<p>In the 1976 book <em>Structured Progamming: Analysis</em>, Dijkstra was reported to have made an analogy between triangles & circles in classical geometry on the one hand and sequencing constructs in programming on the other hand [1, p.42]. Dijkstra openly wondered why mathematicians abundantly use triangles & circles in plane geometry, even though they do not satisfy all their needs. The answer, Dijkstra said, lies in that they provide a great number of general theorems like Pythagoras's Theorem. Therefore, the mathematician can use those results reliably. Likewise, in programming “we wish to stick to a limited set of sequencing primitives”. The few sequencing primitives “are to programming what the triangles and circles are to plane geometry.” [1, p.42]</p>
<p>Dijkstra furthermore relied on the same analogy with mathematics in order to advocate another important idea in his `Notes on Structured Programming': the clear-cut distinction between <em>what </em>an operation does and <em>how </em>it works.</p>
<blockquote><p>There is a strong analogy between using a named operation in a <em>program </em>regardless of “how it works” and using a <em>theorem </em>regardless of how it has been proved. [2, p.11, my emphasis]</p>
</blockquote>
<p>This separation of concerns between <em>what </em>and <em>how </em>was already several years old. <a href="/node/94">Recall that already in 1953 Dijkstra had reasoned along these lines when writing the programming manual for the ARRA II machine.</a> While Dijkstra elaborated on <em>what </em>the ARRA II would offer to the user, his colleagues in Amsterdam (Blaauw, Loopstra, Scholten) built the machine. They were concerned with <em>how</em> the machine would offer the functionality that Dijkstra was putting in writing. In his `Notes on Structured Programming', Dijkstra alluded to his prior work in Amsterdam:</p>
<blockquote><p>There is also an abstraction involved in naming an operation and using it on account of “what it does” while completely disregarding “how it works”. (In the same way one should state that a programming manual describes an abstract machine: the specific piece of hardware delivered by the manufacturer is nothing but a — usually imperfect! — mechanical model of this abstract machine.) [2, p.11]</p>
</blockquote>
<p> </p>
<p>Finally, let me note that the above text is posted on August 6th, 2012. That's exactly 10 years after Dijkstra left our digital world for a more elegant one.</p>
<p> </p>
<p>[1] <em>Structured Programming: Analysis</em>. Infotech International Limited, Maidenhead, 1976.</p>
<p>[2] O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. <em>Structured Programming</em>. Academic Press, London - New York - San Francisco, 1972.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Mon, 30 Jul 2012 15:50:18 +0000egdaylight96 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/96#commentsPhysics and reasoning by analogy
http://www.dijkstrascry.com/node/95
<div class="field field-name-field-histdate field-type-text field-label-inline clearfix"><div class="field-label">Dated: </div><div class="field-items"><div class="field-item even">June 1972</div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>Dahl, Dijkstra, and Hoare's book <em>Structured Programming</em> [1] was published in June 1972. Dijkstra wrote the first chapter, `Notes on Structured Programming', in which he introduced several new ideas. Some of those ideas were a result of his aptitude for mathematics which he had acquired during his teens from his mother (who was a strong mathematician). Other ideas were due to Dijkstra's professional training as a theoretical physicist from Leiden University. </p>
<p>One of Dijkstra's main points was that mathematical techniques for small demonstration programs do not necessarily work for programs a thousand times larger. In his words:</p>
<blockquote><p>Apparently we are too much trained to disregard differences in scale, to treat them as “gradual differences that are not essential”. We tell ourselves that what we can do once, we can also do twice and by induction we fool ourselves into believing that we can do it as many times as needed, but this is just not true! A factor of a thousand is already far beyond our powers of imagination! [1, p.2]</p>
</blockquote>
<p>To clarify, Dijkstra gave two analogies between physical observations and computer programs. The first analogy was about a one-year old child crawling on all fours one mile per hour and a supersonic jet moving at a speed of a thousand miles per hour. “Considered as objects with moving ability the child and the jet are incomparable, for whatever one can do the other cannot and vice versa”. The first object, the child, <em>operates </em>very differently from the second object, the jet, even though both objects move forward. Likewise, for computer programs, one cannot expect a small program to <em>operate </em>like a large program even though both programs compute a function. Hence, one cannot expect to successfully use the <em>same </em>structuring mechanisms for both small and large programs. Dijkstra's second analogy was similar in spirit. He asked the reader to close one's eyes and to imagine standing in a prairie.</p>
<blockquote><p>[W]hile far away a big, reinless horse is approaching at a gallop, one can “see” it approaching and passing. To do the same with a phalanx of a thousand of these big beasts is mentally impossible: your heart would miss a number of beats by pure panic, if you could! [1, p.2]</p>
</blockquote>
<p>It is the operational point of view that I find most intriguing in Dijkstra's reasoning. When writing his `Notes on Structured Programming' (mostly during the late 1960s), Dijkstra viewed a computer program from an operational perspective. Only during the 1970s did Dijkstra become inspired by axiom based reasoning.</p>
<p>For another blog in which I discuss an analogy of Dijkstra with physics, see <a href="/node/91">Turing award lecture — an analogy with physics</a></p>
<p> </p>
<p>[1] O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. <em>Structured Programming</em>. Academic Press, London - New York - San Francisco, 1972.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div></div></div>Mon, 30 Jul 2012 12:10:55 +0000egdaylight95 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/95#commentsThree Snapshots of Dijkstra's Career
http://www.dijkstrascry.com/node/93
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"> <p>“I still remember it well, the day my future husband entered my life”, Ria Debets-Dijkstra recalls. “He was a good-looking man, 20 years of age. He entered our Computing Department with a cane!” [1]. The Computing Department was part of the newly founded Mathematical Centre in Amsterdam. Ria Debets-Dijkstra had already been working there for two years before she saw Edsger Dijkstra on that eventful day in 1951. Dijkstra officially joined the Computing Department in March of the following year. Until 1956, he would work two days a week in Amsterdam and spend the rest of his time studying theoretical physics in Leiden.</p>
<p>During the first ten years of his career, Dijkstra worked as a programmer in Van Wijngaarden's team at the Mathematical Centre in Amsterdam. In 1962 he was appointed professor at the Technische Hogeschool of Eindhoven. And only ten years later, he already received computing's most prestigious prize, the Turing Award. By 1982, he had changed his focus from programming methodology to mathematical methodology and would continue to work on the latter for the next 20 years of his life. He died in August 2002.</p>
<p>In this post I compare and contrast three snapshots of Dijkstra's career, snapshots taken in the years 1960, 1976, and 1982.</p>
<p><span style="text-decoration: underline;"><strong>1960 — In search for a general language</strong></span></p>
<p>As he demonstrated in his 1952 inaugural lecture, Van Wijngaarden was very keen on connecting natural languages with programming languages when Dijkstra joined the Mathematical Centre. With hindsight, it is no surprise to see ideas similar to Van Wijngaarden's expressed in some of Dijkstra's early writings (see e.g. <a href="http://www.cs.utexas.edu/users/EWD/MCReps/MR34.PDF">MR 34: `On the Design of Machine Independent Programming Languages'</a>).</p>
<p>Around 1960, Dijkstra and Van Wijngaarden viewed ALGOL60 as a programming language containing unneeded restrictions. They wanted to discard those restrictions and devise a <em>general </em>language instead. Van Wijngaarden's persistence in this regard eventually led to the definition of ALGOL68.</p>
<p>An example of an unneeded restriction — that fortunately was not part of ALGOL60 thanks to Van Wijngaarden's and Dijkstra's prior efforts — was a procedure that can call another procedure but not itself. By discarding that restriction, one obtains a more general and hence simpler language; i.e. a language that can handle recursive procedures. For further details, see my two previous posts: <a href="/node/75">`An analogy between mathematics and programming'</a> and <a href="/node/78">`Dijkstra's Unification versus the Case Distinctions of Irons & Feurzeig'</a>.</p>
<p><span style="text-decoration: underline;"><strong>1976 — In search for intellectual manageability </strong></span></p>
<p>Like so many others, Dijkstra was a computer programmer who had no training in mathematical logic. Only in the early 1970s did Dijkstra become a supporter of Hoare's logical approach to programming language semantics. [2, p.346].</p>
<p>According to Dijkstra, it was Hoare who showed the computing community that <strong>intellectual manageability of programs critically depends on the specific choice of linguistic constructions</strong>. On the one hand, the programming language should offer combinatorial freedom. On the other hand, if too much freedom is provided, then the language may be intellectually unmanageable (and, as a possible result, difficult to implement). For example, a language containing procedure calls, and hence also recursive procedure calls, is intellectually unmanageable.</p>
<p>So Dijkstra's support for Van Wijngaarden's linguistic ideals faded. Dijkstra learned from Hoare that a computing scientist should, on the one hand, try to generalize the task he has to solve but, on the other hand, avoid introducing generalizations that are intellectually difficult to manage in the first place. [3, p.10-11] Too much combinatorial freedom can be detrimental.</p>
<blockquote><p>[Dijkstra] advocated many restrictions on programming language constructs, but always with the problems of program correctness in mind, of showing the correctness of a program. In 1976, in <em>A Discipline of Programming</em>, he even dropped the recursive procedure altogether [...]</p>
</blockquote>
<p>This comment is from an anonymous reviewer for Chapter 3 in my book <em>The Dawn of Software Engineering: from Turing to Dijkstra</em>. The comment characterizes Dijkstra's thinking of the 1970s and stands in sharp contrast to the way Dijkstra thought about programming, and recursion in particular, during the early 1960s. What Dijkstra considered to be simple (and elegant) in 1960 was not necessarily simple in 1976.</p>
<p><span style="text-decoration: underline;"><strong>1982 </strong></span><span style="text-decoration: underline;"><strong>—</strong></span><span style="text-decoration: underline;"><strong> A program text represents a predicate</strong></span></p>
<p>During the 1980s, calculational reasoning became Dijkstra's main occupation. Instead of viewing a program text as an operational description of an abstract machine as he had done during the 1960s, Dijkstra viewed a program text as a formula in a formal system. The formula represents a predicate. In his words:</p>
<blockquote><p>Each program text [... represents ...] a predicate on the Cartesian product of the so-called initial state space and the final state space. [4, p.1]</p>
</blockquote>
<p>Furthermore, the activity of formally deriving a program from its specification is a constructive form of predicate calculus — constructive because the predicate has to allow for the interpretation of automatically executable code.</p>
<p> </p>
<p>Mathematical logic entered the arena of computing science in various guises but primarily by researchers who were <em>not</em> mathematical logicians (— a central theme in my book <em>The Dawn of Software Engineering</em>). It is precisely this historical interplay between ideas from mathematical logic and their counterparts in computing science which, I believe, can serve well in grasping the basics of our field.</p>
<p> </p>
<p>[1] Paraphrased words from an interview with Ria Debets-Dijkstra in December 2011.</p>
<p>[2] E.W. Dijkstra. <a href="http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1308.PDF">“EWD 1308: What led to Notes on Structured Programming”</a>. In: Software pioneers: contributions to software engineering. Ed. by M. Broy and E. Denert. Springer, 2002, pp. 341–346.</p>
<p>[3] E.W. Dijkstra. <a href="http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD325.PDF">"EWD 325: Poging tot plaatsbepaling van de informatica"</a>, pp. 0-14.</p>
<p>[4] E.W. Dijkstra. <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD819.PDF">"EWD 819: Mathematical Induction and Computing Science"</a>, 4 April 1982, pp. 0-7.</p>
</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags: </div><div class="field-items"><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/8" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary60s</a></div><div class="field-item odd" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></div><div class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></div></div></div>Fri, 08 Jun 2012 11:27:41 +0000egdaylight93 at http://www.dijkstrascry.comhttp://www.dijkstrascry.com/node/93#comments