Dijkstra's Rallying Cry for Generalization - diary80s
https://dijkstrascry.com/taxonomy/term/10
My diary on what Dijkstra did in the 1980s.
Picture on the right: Edsger and his student Netty van Gasteren sitting behind Edsger's desk in his home in Nuenen. Notice the two telephones.
en`Plato and the Nerd,' Part 2b: Computer Science & Descriptions vs. Software Engineering & Prescriptions
https://dijkstrascry.com/Lee2b
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">23 September 2017</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p> </p>
<p>One of Edward A. Lee's main topics in his book, <a href="http://www.platoandthenerd.org/index.html"><em>Plato and the Nerd: The Creative Partnership of Humans and Technology</em></a> (MIT Press, 2017), is the contradistinction between science and descriptions on the one hand and engineering and prescriptions on the other hand. Reading between the lines, Lee is addressing the big question: <strong>Is computer science really a science?</strong></p>
<p>Based on the writings of Donald MacKenzie [13], Timothy Colburn [2], and Matti Tedre [21], I have become skeptical about computer scientists calling themselves scientists, a topic also raised in discussions with Peter Naur [3] and Donald Knuth [10,11]. (An analysis of these writings lies outside the scope of the present column.) My first impression from reading Lee's book is that he, too, is skeptical. For example, he quotes John Searle from 1984 as follows:</p>
<blockquote><p>“... anything that calls itself “science” probably isn't ...” [12, p.20]</p>
</blockquote>
<p>My second impression about Lee's thoughts are more nuanced and based on `the Kopetz Principle,' which I introduced in <a href="http://www.dijkstrascry.com/Lee1">my first post pertaining to Lee's book</a>. (And by the way here's <a href="http://www.dijkstrascry.com/Lee2a">a link to my second post on Lee's book</a>.) Recall specifically the following explanation about the Kopetz Principle:</p>
<blockquote><p>We can make definitive statements about models, from which we can infer properties of system realizations. The validity of this inference depends on <span style="text-decoration: underline;"><em>model fidelity</em></span>, which is always approximate.<br />— citing from Lee's 2012 talk, entitled: <a href="https://www.youtube.com/watch?v=O_0FDUsFXaY">`Verifying Real-Time Software is Not Reasonable (Today)'</a></p>
</blockquote>
<p>These 2012 words beg the question: How to get a good model fidelity? Lee addresses this question with several insightful examples in his 2017 book. My interest lies in Lee's distinction between two mechanisms on how to use models: the <strong>Scientific Mechanism</strong> and the <strong>Engineering Mechanism</strong> [12, p.42].</p>
<p> </p>
<p><strong>TWO MECHANISMS</strong></p>
<p>I shall now elaborate on Lee's two mechanisms. The bold-faced names are of my choosing and so are several examples.</p>
<ul><li>The <strong>Scientific Mechanism</strong> amounts to choosing a model that is faithful to the modellee. A scientist will study nature and subsequently choose or invent a model that s/he deems is useful. For example, the laws of classical mechanics (= model) are an attempt to capture and predict motions in our physical world (= modellee). The world is given and the model is of the scientist's making.</li>
</ul><ul><li>The <strong>Engineering Mechanism</strong> amounts to choosing or producing a modellee that is faithful to the model. For example: a construction engineer uses a blueprint (= model) as a guide to construct a building (= modellee). Another example: a software engineer uses a flowchart (= model) to produce a computer program (= modellee), as explained in <a href="../node/152">my post on flowcharts</a>.</li>
</ul><p>Lee stresses that both scientists and engineers assume that the “target” (= modellee) is “operating within some regime of applicability of the model” [12, p.42]. Now the big question:</p>
<blockquote><p>Does a computer scientist work (mostly) in compliance with the Scientific Mechanism or (mostly) with the Engineering Mechanism?</p>
</blockquote>
<p>In other words: <strong>Is computer science really a science?</strong> If so, then a computer scientist, just like other scientists, “constructs models to help understand the target,” i.e., to understand the modellee [12, p.45]. If not, then perhaps a computer scientist is more like an engineer in that s/he</p>
<blockquote><p>constructs <span style="text-decoration: underline;"><em>targets</em></span> to emulate the properties of a model. An engineer uses or invents models for things that <span style="text-decoration: underline;"><em>do not exist</em></span> and then tries to construct physical objects (targets) for which the models are reasonably faithful. [12, p.45, original emphasis]</p>
</blockquote>
<p>For simplicity, I only focus on first-generation computer scientists for now; that is, on researchers in the 1950s and early 1960s for whom the “target” or the “modellee” was the <em>stored-program computer</em>. Indeed, by the late 1940s the stored-program computer existed in nature — if the term “nature” is allowed to be construed broadly; that is, to include engineered artifacts. The stored-program computer had become a “given” for Alan Perlis, Saul Gorn, John Carr, and many other researchers who, by the mid-1960s, would be called “computer scientists.” Again, many of these soon-to-be-called computer scientists were looking for adequate mathematical models for the few stored-program computers that were available in the 1950s and 1960s. (See my article on Turing's legacy [5] and the references therein.)</p>
<p>With regard to theoretical computer scientists, and complexity theorists in particular, a similar story is told by Michael Mahoney [14] — where, for example, the linear bounded automaton was (at some point and by some actors) considered less baroque than the Turing machine in order to mathematically capture physical computations. So, also theoretical computer scientists sought mathematical models in compliance with the Scientific Mechanism. I refer to my second oral history with Knuth [11] and also to my latest book [6] for more coverage.</p>
<p>In sum, then, I think it is quite right after all to call somebody like Saul Gorn a `<em>computer scientist</em> of the first hour.' The only small caveat is that the word “science,” as Lee explains,</p>
<blockquote><p>refers to the study of nature, not to the study or creation of artificial artifacts. Under this interpretation, many of the disciplines that call themselves a “science,” including computer science, are not, even if they do experiments and use the scientific method. [12, p.21]</p>
</blockquote>
<p>Therefore, and as already indicated above, I wish to broaden the notion of “nature,” so that it encompasses engineered artifacts as well. Alternatively, we could place “computer science” in a category other than “science” as long as it remains distinct from “software engineering.”</p>
<p>Of course many historical actors were and many contemporary actors are <em>both</em> scientists and engineers — a point that also Lee makes in his book. In my opinion many computer scientists are more software engineers than they would be willing to admit. This brings me to yet another theme in Lee's book, which I only mention in passing: traditionally, engineering is less respected than science. (And several engineers — as Lee illustrates — have advanced science.) Related remarks about the tendency to place mathematical rigor above all else have been made by Walter Vincenti [22], Peter Naur [17], Michael Jackson [9], and others.</p>
<p> </p>
<p><strong>DESCRIPTIONS vs. PRESCRIPTIONS</strong></p>
<p>Saul Gorn and fellow computer scientists of the first hour were appropriating and re-casting Turing's 1936 `automatic machines,' which led to Martin Davis's 1958 concept of a `Turing machine' [1]. In a nutshell: Gorn et al. were looking for a good mathematical <strong>description</strong> of existing computing machinery. Again, I try to convey Lee's two mechanisms in my own words:</p>
<ul><li>The <strong>Scientific Mechanism</strong> amounts to choosing a good description. A <strong>description</strong> is an account of some event. An example of a description is (a textual representation of) the second law of thermodynamics.</li>
<li>The <strong>Engineering Mechanism</strong> amounts to abiding by a prescription. A <strong>prescription</strong> is a recommendation that is authoritatively put forward. An example of a prescription is a blueprint (printed on paper) of a building.</li>
</ul><p>As explained in my article on Turing's legacy, Gorn was lecturing about Turing machines all over the place by the early 1960s. In that period of his life he was first and foremost a computer <em>scientist</em>, not an engineer. Observations such as these help me now to understand:</p>
<ul><li>Why many computer science courses contain the words “Turing machine” and “Chomsky hierarchy” and the like.</li>
<li>Why many software engineering courses hardly if at all rely on the “Turing machine” concept.</li>
</ul><p>It simply does not make much sense to use a Turing machine as a prescriptive device in the world of software engineering (although there are exceptions).</p>
<p>I was initially trained as a software engineer (1995-2000) and as a student I only came across the words “Turing machine” in an appendix of a book on code theory(!) Times have changed for software engineering students at my local university (KU Leuven) for now they follow a course on computability theory. Of course curricula are different across countries and continents; nevertheless, I don't think my personal experience is too far off from that of many fellow software engineers of my generation or before. Take Dave Parnas for example. He told me that he <em>did</em> learn a lot about Turing machines but primarily (if not solely) from Alan Perlis, a <em>computer scientist</em> of the first hour (not to mention that Perlis was the very first Turing Award winner). Moreover, my educated guess is that Parnas does not consider Turing machines to be central to his profession [18, p.26-28].</p>
<p>But now irony sets in because I will try to show that, in accordance with the two above-stated mechanisms, Parnas was more of a computer scientist than Edsger Dijkstra, and <a href="../node/104">Dijkstra was more of a software engineer</a> than Parnas. To convey this message I will first zoom in on a fundamental problem in computing.</p>
<p>In the rest of this column I shall use the words “computer programmer” as an umbrella term. Specifically:</p>
<ul><li>Both computer scientists and software engineers are “computer programmers.”</li>
<li>A “computer programmer” need not be a computer scientist nor a software engineer.</li>
</ul><p> </p>
<p><strong>DIFFERENT VIEWS TO A FUNDAMENTAL PROBLEM</strong></p>
<p>Regardless of whether you are more, or you think you are more, a computer scientist than a software engineer or the other way around, computer programmers across the globe are faced with an overarching difficulty: according to Parnas in 1985, we “will never find a process that allows us to design software in a perfectly rational way” [19, p.251]. A similar concern was raised by Peter Naur in the same year [15], reprinted in his 1992 book:</p>
<blockquote><p>[T]he notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. [16, p.47-48]</p>
</blockquote>
<p>To put it bluntly, both Parnas and Naur opposed the over-rational research agendas of Dijkstra, Tony Hoare, and other formal methodists. In Parnas's words:</p>
<blockquote><p>Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen. [19, p.252]</p>
</blockquote>
<p>Similar criticism has been conveyed by Niklaus Wirth [4, Ch.5] and Michael Jackson [9].</p>
<p>Clearly, Parnas and Naur had much in common in 1985. <a href="../node/144">Both men viewed a computer program as a <em>non-mathematical</em> model of the real world</a>. Moreover, for Naur the entire development and maintenance process of software is not fully describable, not even in principle [3]. In Naur's 1985 words:</p>
<blockquote><p>[T]he program text and its documentation has proved insufficient as a carrier of some of the most important design ideas. [16, p.39]</p>
</blockquote>
<p>Naur says that if a software company loses all its programmers, then it better rebuilds its software <em>from scratch</em> (with a new team of programmers). All existing code and documentation will be of little value to other experts [3].</p>
<p>I take this strong viewpoint of Naur to align well with Lee's perspective: “knowing” a function — such as a development and maintenance process — does not imply that you can “describe that function in some mathematical or natural language” [12, p.177]; i.e. that you can rigorously document all of your work. The main reasons for Lee to come to this conclusion are, unlike Naur, based on Information Theory and Kolmogorov-Chaitin Complexity Theory. (Lee's expositions about Shannon's theoretical results are an absolute delight to read.) The argument from Complexity Theory, provided in more technical terms on page 158, amounts to the following observation (in Lee's own words):</p>
<blockquote><p>Given any written mathematical or natural language, the vast majority of functions with numerical input and output are not describable in that language. This is because every description in any such language is a sequence of characters from a finite alphabet of characters, so the total number of such descriptions is countable. There are vastly more functions, so there can't possibly be descriptions for all of them in any one language. In fact, any language will only be able to describe a tiny subset of them, a countable infinite subset. Does a function need to be describable to be useful? [12, p.177]</p>
</blockquote>
<p>See <a href="http://www.dijkstrascry.com/Lee2a">my previous post</a> for some useful functions that are not necessarily describable.</p>
<p>Naur and Lee have approached the same topic from different angles and both strongly oppose a rational metaphysical view to our world. The same can be said about Lucy Suchman, who works in yet another field: Human Computer Interaction. I view Suchman as someone who in 1987 also tackled the aforementioned overarching problem in computer programming but from a social-studies perspective. (I quote her below, not from her original 1987 book but from the 2007 edition [20].) With regard to instruction following between people, Suchman wrote:</p>
<blockquote><p>Social studies of the production and use of instructions have concentrated on the <em><span style="text-decoration: underline;">irremediable incompleteness of instructions</span></em> (Garfinkel 1967, Chapter 1) and the nature of the work required to “carry them out.” [20, p.112, my emphasis]</p>
</blockquote>
<p>The emphasized words, attributed to Harold Garfinkel [8, Ch.1], are akin to the views put forth by Naur and Lee. (Am I exaggerating if I interpret the previous passage as an alternative formulation of the Kopetz Principle, which — once again — states that the model fidelity is always approximate and, thus, that the model is irremediably incomplete?) Concerning the term “instructions” in the previous quote, think about the instructions that somebody gives you to go from point A to point B. Alternatively, and more in connection with Parnas's and Naur's writings, think of the instructions (e.g. software requirements, formalized specifications, program text, sequence diagrams, ...) that you, as a novice programmer in a software company, need to examine in order to (allegedly) be able to grasp all the technicalities of the software project at hand. As we shall see later, Parnas said in 1985 that achieving such insight from documentation alone <em>is</em> feasible in principle. Naur, in contrast, said that human involvement remains key; that is, good documentation and code only get you so far.</p>
<p>Coming back to Suchman. Once again, she wrote about instruction following between people (and between people and machines). Both a prescriptive account (of an instruction that shall be carried out) and a descriptive account (of an instruction that has been carried out) are merely approximations to the real happening. In her own words:</p>
<blockquote><p>[S]uccessful instruction following is a matter of constructing a particular course of action that is accountable to the general description that the instruction provides. <em><span style="text-decoration: underline;">The work of constructing that course is neither exhaustively enumerated in the description, nor completely captured by a retrospective account of what was done.</span></em> [20, p.112, my emphasis]</p>
</blockquote>
<p>The emphasized words support Lee's and Naur's views, not those of Parnas. According to Parnas in 1985 it <em>is</em> possible to completely capture the software-design process in a retrospective account. Indeed, he insisted that there is “good news” in that we “can fake” the actual, irrational design process. Specifically,</p>
<blockquote><p>We can present our system to others <span style="text-decoration: underline;"><em>as if we had been rational</em></span> designers and it pays to pretend [to] do so during development and maintenance. [19, p.251, my emphasis]</p>
</blockquote>
<p>Many of us, myself included, do try to work like this in the software industry. And before coming across the writings of Naur in 2010 I used to really believe Parnas's claim that:</p>
<blockquote><p>... the final documentation will be rational and accurate. [19, p.256]</p>
</blockquote>
<p>We can “fake” the process, Parnas wrote, by</p>
<blockquote><p>producing the documents that <span style="text-decoration: underline;"><em>we would have produced</em></span> if we had done things the ideal way. [19, p.256, my emphasis]</p>
</blockquote>
<p>Just like Suchman, Naur would insist that there is no “ideal way,” that we cannot be “accurate,” especially when the human is taken out of the loop to begin with. Moreover, human beings do not, according to Naur, perform like machines:</p>
<blockquote><p>[M]uch current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily. Another related view is that human beings perform best if they act like machines, by following rules, ... [16, p.47]</p>
</blockquote>
<p>In sum, both Parnas and Naur criticized the programming methodology work of Dijkstra et al., but Naur went a few steps further.</p>
<p> </p>
<p><strong>AN OVERVIEW</strong></p>
<p>A synthesis is starting to emerge as I write these posts on Lee's 2017 book and the history of formal methods in computer science. Observe, for instance, that Parnas's “faked” approach amounts to choosing a good <strong>description</strong> of the prior, irrational software-design process, conducted by humans. Parnas thus advocated the Scientific Mechanism, believing that it <em>is</em> possible to obtain a rational and complete description of a real-life software-engineering event. Dijkstra with his prescribed top-down programming methodology, in contrast, followed the Engineering Mechanism more than Parnas. The irony is that Parnas will be remembered as a software engineer <em>pur sang</em>, and Dijkstra mostly as a computer scientist (instead of the other way around). With that said, and <a href="../node/104">as I've discussed before, Dijkstra and Hoare did call themselves “software engineers” in the 1960s and 1970s</a> — an observation that is now starting to make more sense (to me).</p>
<p>All in all, some of my thoughts, particularly about the second half of the 1980s, can now be summarized:</p>
<ol><li>Parnas said that the we can get an accurate <strong>description</strong> of the software-design process (cf. the Scientific Mechanism), not a perfect <strong>prescription</strong>.</li>
<li>Naur said that we can't even get an accurate <strong>description</strong>. I take both Lee's and Suchman's philosophies to align quite well with Naur's views. </li>
<li>Dijkstra and Hoare, in turn, were much more receptive to the idea that we can get a rational and complete <strong>prescription</strong>; that is, a recommendation that is authoritatively put forward on how to rationally develop “correct-by-construction” software (cf. the Engineering Mechanism).</li>
</ol><p>To conclude, I guess it comes as no surprise when I now explicitly express my preference for the viewpoints of Naur, Lee, and Suchman. I used to be a strong advocate of formal methods. See e.g. my work on `correct-by-construction' C code for embedded systems [7]. But today I am more receptive to the idea that learning to program, or grasping the code of a colleague, is like learning to play a new instrument. Software is like music. In Naur's words:</p>
<blockquote><p>This problem of education of new programmers ... is quite similar to that of the educational problem of other activities where the knowledge of how to do certain things dominates over the knowledge that certain things are the case, such as writing and playing a music instrument. [16, p.44]</p>
</blockquote>
<p>If the analogy between software and music is warranted, then teaching students how to program is similar to teaching how to play a musical instrument. This observation has ramifications for curricula of computer science and software engineering alike. In Naur's words:</p>
<blockquote><p>To what extent this can be taught at all must remain an open question. The most hopeful approach would be to have the student work on concrete problems under guidance, in an active and constructive environment. [16, p.48]</p>
</blockquote>
<p>There is of course much more to be said. Lee, Naur, and Suchman are only three of many proponents who strive for <a href="http://www.platoandthenerd.org/index.html">a creative partnership of humans and technology without equating one with the other</a>.</p>
<p> </p>
<p><strong>REFERENCES</strong></p>
<p><strong>[1]</strong> M. Bullynck, E.G. Daylight, and L. De Mol. Why did computer science make a hero out of Turing? Communications of the ACM, 58(3):37-39, March 2015.<br /><strong>[2]</strong> T.R. Colburn. <em>Philosophy and Computer Science</em>. M.E. Sharpe, 2000.<br /><strong>[3]</strong> E.G. Daylight. <em>Pluralism in Software Engineering: Turing Award Winner Peter Naur Explains</em>. Lonely Scholar, 2011.<br /><strong>[4]</strong> E.G. Daylight. <em>The Dawn of Software Engineering: from Turing to Dijkstra</em>. Lonely Scholar, 2012.<br /><strong>[5]</strong> E.G. Daylight. Towards a Historical Notion of `Turing the Father of Computer Science'. History and Philosophy of Logic, 36(3):205-228, 2015.<br /><strong>[6]</strong> E.G. Daylight. <em>Turing Tales</em>. Lonely Scholar, 2016.<br /><strong>[7]</strong> E.G. Daylight, A. Vandecappelle, and F. Catthoor. The formalism underlying EASYMAP: a precompiler for refinement-based exploration of hierarchical data organizations. Science of Computer Programming, 72(3):71-135, August 2008.<br /><strong>[8]</strong> H. Garfinkel. <em>Studies in ethnomethodology</em>. Englewood Clifs, NJ: Prentice Hall, 1967.<br /><strong>[9]</strong> M.A. Jackson and E.G. Daylight. <em>Formalism and Intuition in Software Development</em>. Lonely Scholar, August 2015.<br /><strong>[10]</strong> D.E. Knuth and E.G. Daylight. <em>The Essential Knuth</em>. Lonely Scholar, 2013.<br /><strong>[11]</strong> D.E. Knuth and E.G. Daylight. <em>Algorithmic Barriers Falling: P=NP?</em> Lonely Scholar, 2014.<br /><strong>[12]</strong> E.A. Lee. <em>Plato and the Nerd: The Creative Partnership of Humans and Technology</em>. MIT Press, 2017.<br /><strong>[13]</strong> D. MacKenzie. <em>Mechanizing Proof: Computing, Risk, and Trust</em>. MIT Press, 2004.<br /><strong>[14]</strong> M.S. Mahoney. <em>Histories of Computing</em>. Harvard University Press, 2011.<br /><strong>[15]</strong> P. Naur. Programming as theory building. Microprocessing and Microprogramming, 15:253-261, 1985.<br /><strong>[16]</strong> P. Naur. <em>Computing: A Human Activity</em>. ACM Press / Addison-Wesley, 1992.<br /><strong>[17]</strong> P. Naur. <em>Knowing and the Mystique of Logic and Rules</em>. Kluwer Academic Publishers, 1995.<br /><strong>[18]</strong> D.L. Parnas. Software engineering programs are not computer science programs. IEEE Software, 16(6):19-30, 1999.<br /><strong>[19]</strong> D.L. Parnas and P.C. Clements. A rational design process: how and why to fake it. In H. Ehrig, C. Floyd, and M. Nivat, editors, <em>TAPSOFT Joint Conf. on Theory </em><em>and Practice of Software Development</em>, Berlin, March 1985. Springer-Verlag.<br /><strong>[20]</strong> L.A. Suchman. <em>Human-Machine Recongurations: Plans and Situated Actions</em>. Cambridge University Press, second edition, 2007.<br /><strong>[21]</strong> M. Tedre. <em>The Science of Computing: Shaping a Discipline</em>. Taylor and Francis, 2014.<br /><strong>[22]</strong> W.G. Vincenti. <em>What Engineers Know and How They Know It: Analytical Studies from Aeronautical History</em>. Johns Hopkins University Press, 1990.</p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li><li class="field-item odd" rel="dc:subject"><a href="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Sat, 23 Sep 2017 10:31:45 +0000egdaylight155 at https://dijkstrascry.comhttps://dijkstrascry.com/Lee2b#commentsDijkstra's "Computer Scientist" in 1982
https://dijkstrascry.com/node/105
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">1982</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>During Dijkstra's career at Eindhoven programming had developed from an art to a science. But, by 1982 there was still insufficient official recognition for this development. From Dijkstra's perspective, computer programmers had yet to be taken seriously in the world at large. This observation helps explain why, a year prior, he had warmly welcomed the new journal called <em><strong></strong>Science of Computer Programming</em>. In his words:</p>
<blockquote><p>“Science of Computer Programming” [should help end] the current sate of affairs in which <strong>managers </strong>see programming primarily as a management problem because they cannot manage it, in which <strong>electronic engineers</strong> don't see the problem and in which <strong>mathematicians </strong>ignore it. [<a href="http://www.cs.utexas.edu/users/EWD/ewd07xx/EWD777.PDF">EWD777</a>, p.1, my emphasis]</p>
</blockquote>
<p>In my previous post, I showed that <a href="/node/104">Dijkstra used the words “software engineer” to describe himself in 1972</a>. By the early 1980s, however, he had started to call himself a “computer scientist” (i.e. a “mathematische informaticus”). He described “computer science” as</p>
<blockquote><p>The study of information processing by means of algorithms in which one abstracts from specific application domains and specific implementation techniques. [Paraphrased translation from my archives: <em>Lectori Salutem!</em>, 4 Dec. 1981]</p>
</blockquote>
<p>Dijkstra stressed that “computer science” encompassed “theoretical computer science”. The latter term referred to the logical foundations of computer science and did not include his own research. To highlight the mathematical nature of “computer-science” research, Dijkstra quoted Ralston & Shaw as follows:</p>
<blockquote><p>[W]here mathematical reasoning plays little or no role in an area of computer science, that portion of our discipline is still in its infancy and needs the support of mathematical thinking if it is to mature. [see p. 69 in Ralston & Shaw's 1980 article: <em><span class="title">Curriculum '78 - Is Computer Science Really that Unmathematical?</span></em> CACM 23(2): 67-70.]</p>
</blockquote>
<p>“Computer science”, Dijkstra wrote, will evolve and become a mature branch of mathematics. To contribute to this evolution, computer scientists should promote and use formal methods, and extract from the many computer applications those fundamental problems that can be studied in relative isolation.</p>
<p>[Paraphrased translation from <em>Lectori Salutem!</em>]</p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Fri, 11 Jan 2013 14:54:05 +0000egdaylight105 at https://dijkstrascry.comhttps://dijkstrascry.com/node/105#commentsThree Snapshots of Dijkstra's Career
https://dijkstrascry.com/node/93
<div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><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><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/8" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary60s</a></li><li class="field-item odd" rel="dc:subject"><a href="/taxonomy/term/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</a></li><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Fri, 08 Jun 2012 11:27:41 +0000egdaylight93 at https://dijkstrascry.comhttps://dijkstrascry.com/node/93#commentsUnifying Seemingly Disparate Sorting Algorithms
https://dijkstrascry.com/node/92
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">18 January 1982</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>In their joint report <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD809.PDF">`An introductory essay on three algorithms for sorting in situ'</a>, Van Gasteren and Dijkstra explain what Insertion Sort, Heap Sort, and Smooth Sort have in common and how one can derive one sorting algorithm from the other. </p>
<p>Insertion Sort can be explained in terms of a descending chain in the following manner. During each iteration of Insertion Sort for a list of N elements, the descending chain grows with one new element: the descending chain of length n and a new element are transformed into a new descending chain of length n+1. At the end of the day, the descending chain represents the sorted list of N elements. Insertion Sort thus depends on a <em>growing descending chain</em> which is initially of size 0 and finally of size N.</p>
<p>By generalizing the notion of a chain into a tree, Van Gasteren and Dijkstra continue by describing a family of related sorting algorithms, a family which contains the Heap Sort and Smooth Sort algorithms as special cases. A chain is, after all, a tree of a special form.</p>
<blockquote><p>An attractive <em>generalization </em>of a chain is a rooted tree. Analogously [to a descending chain], a descending tree is one in which each element dominates its entire offspring. <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD809.PDF">[p.4, my emphasis]</a></p>
</blockquote>
<p>It should be stressed, however, that the descending tree in Heap Sort or Smooth Sort serves another purpose than the descending chain in Insertion Sort. During each iteration of Insertion Sort, the descending chain <em>grows </em>with one element. During each iteration of Heap Sort or Smooth Sort, the descending tree <em>shrinks</em> with one element. In the case of Insertion Sort, the descending chain represents the sorted part of the list. In the case of Heap Sort or Smooth Sort, the descending tree represents the part of the list that has not been sorted.</p>
<p>During each iteration in Heap Sort or Smooth Sort, the descending tree of size n+1 splits into its root r, on the one hand, and a new descending tree of size n, on the other hand. The root r adjoins the already sorted list of elements, a list that grows by one element in each iteration. To obtain the new descending tree of size n from all the offspring of root r, some appropriate reshuffling is needed. This reshuffling can be implemented in terms of a growing descending tree, which is initially of size 0 and finally of size n. To accomplish that, one has to judiciously choose a path in the growing descending tree (of final size n) and <em>apply the same ideas underlying the growing descending chain of Insertion Sort</em>. Here, thus, lies a strong similarity between all three sorting algorithms. </p>
<p>Finally, I mention that Heap Sort and Smooth Sort differ in how the reshuffling is implemented. For further details, <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD809.PDF">see [AvG16/EWD809]</a>.</p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Thu, 24 May 2012 13:08:27 +0000egdaylight92 at https://dijkstrascry.comhttps://dijkstrascry.com/node/92#commentsA letter about APL
https://dijkstrascry.com/node/90
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">Tuesday 12 January 1982</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>On Tuesday 12 January 1982, Dijkstra wrote a letter to Dr. A. Caplin explaining why he had his reservations about the language <strong>APL</strong> (<strong>A P</strong>rogramming <strong>L</strong>anguage). Dijkstra did this in response to an earlier letter that he had received from Caplin, a letter in which Caplin asked whether Dijkstra favored APL and, if not, why not. In Caplin's words:</p>
<blockquote><p>[I] was struck by [...] your search for a notation from mathematics that ``embraces all the required concepts of programming as well as enforcing the discipline of scientific method''. Surely you know that one such notation [APL] does exist, and was worked on by Ken Iverson in Harvard as far back as 1957. [...] Perhaps you have looked at it and dismissed it --- if so, why?</p>
</blockquote>
<p>Ken Iverson was the 1979 Turing Award winner. His APL language inspired many researchers, including Donald Knuth and Gerrit Blaauw.</p>
<p>The Dutch engineer Blaauw was a colleague of Howard Aiken during the late 1940s and early 1950s, a colleague of Dijkstra in Amsterdam during the early to mid 1950s, and an employer of IBM in New York from the mid 1950s to the mid 1960s. </p>
<p>After working with Aiken in Harvard, Blaauw brought a lot of know-how with him when he joined the Amsterdam team in 1952. Blaauw showed Dijkstra's colleagues, Loopstra and Scholten, how to build reliable computers that actually work. In 1955, Blaauw left the Netherlands again, this time to join IBM in New York. He became famous during the early 1960s after introducing his three levels of concern: architecture, implementation, and realization. Blaauw was a leading architect of the IBM System 360 together with Fred Brooks and fell in love with Iverson's APL notation.</p>
<p>In 1965, Blaauw returned to the Netherlands to start an academic career at the recently founded Technische Hogeschool Twente. Blaauw taught his students how to design the IBM way. He advocated using one general language, APL, to design both the software and hardware of a computer. Blaauw's design approach was one of prototyping: first build a prototype of the system (by programming in APL), experiment with that prototype and only afterward start implementing the real system. </p>
<p>Blaauw's emphasis on prototyping contrasts with what Dijkstra was delivering in Eindhoven during the 1960s. In fact, already during his earlier years in Amsterdam, Dijkstra wanted to prove a program correct by mathematical reasoning alone. Testing, as advocated by Blaauw, was a last resort to Dijkstra. Nevertheless, even though Blaauw and Dijkstra had different design philosophies, they did remain friendly (albeit somewhat distant) colleagues for the rest of their careers.</p>
<p>Contrasting Blaauw's design perspective with that of Dijkstra helps us understand Dijkstra's response to Caplin's letter. In Dijkstra's words:</p>
<blockquote><p>A typical characteristic of the APL devotee is, for instance, his closeness to an implementation of it. I know of a visiting professor at an American University who, trying to teach APL, bitterly complained about the absence of APL terminals. He was clearly unable to teach it without them. [...] This is in sharp contrast to people who prefer programming languages that can be adequately ``demonstrated'' ---i.e. shown, taught and discussed--- with pencil and paper.</p>
</blockquote>
<p>Abstraction from the machine is what, according to Dijkstra, APL failed to offer.</p>
<p>Source: both letters are in my archive (Map 1: T.U.E. 1973-1984).</p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Thu, 05 Apr 2012 15:11:12 +0000egdaylight90 at https://dijkstrascry.comhttps://dijkstrascry.com/node/90#commentsExploiting Symmetry
https://dijkstrascry.com/node/86
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">November 1981</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>In his 1963 paper `On the design of machine independent programming languages' Dijkstra explained why he wanted to avoid using case distinctions in the design of a programming language. For example, a programming language that allows a procedure to call another procedure but not itself was unneeded sophistication according to Dijkstra. Such a restriction not only complicates the definition of the language (by introducing a case distinction), it also complicates the task of implementing the language. Details are presented in my <a href="/node/4">`Dijkstra's Rallying Cry ...' article</a>. See also my previous post on <a href="/node/78">the case distinctions of Irons and Feurzeig</a>.</p>
<p>Almost 20 years later, Dijkstra explained why case distinctions are preferably also avoided when reasoning mathematically. Consider the following example:</p>
<ul><li>Let each of the 15 edges of a complete 6-graph be either red or blue.</li>
</ul><ul><li>3 of the nodes form a "monochrome triangle" when the 3 edges connecting them are of the same color.</li>
<li>Prove the existence of at least one monochrome triangle.</li>
</ul><p>It is very tempting to start the proof by taking an arbitrary node and giving it a name X and to then enumerate over different cases as follows:</p>
<blockquote><p>Among the 5 edges meeting X, one of the two colors, say red, dominates. Let XP, XQ, and XR be three red edges. <br />+ Case 1: Triangle PQR has a red edge, PQ say. Then triangle XPQ is monochrome red.<br />+ Case 2: Triangle PQR has no red edge. Then triangle PQR is monochrome blue.</p>
</blockquote>
<p>Dijkstra was unsatisfied with the above proof because it destroys the intrinsic symmetries of the problem. Saying that the color red dominates over the color blue destroys the symmetry between the two colors. Furthermore, naming one node X and another node P destroys the symmetry between the nodes as well.</p>
<p>To exploit the aforementioned symmetries, Dijkstra introduced the following definitions:</p>
<ul><li>Call two edges of different color and having one node in common a "mixed V" meeting at that node.</li>
</ul><ul><li>Call a triangle "bichrome" if it is not a monochrome triangle.</li>
</ul><p>In this particular problem there is no need to distinguish between the nodes (and giving them a unique name). Just take an arbitrary node, notice that it has 5 edges, and hence, note that at most 2*3 = 6 mixed V's meet at that node. Continue as follows:</p>
<ul><li>Since there are 6 nodes, there are at most 6*6 = 36 mixed V's.</li>
<li>Each mixed V occurs in one bichrome triangle.</li>
<li>Each bichrome triangle contains two mixed V's.</li>
<li>Hence, there are at most 36/2 = 18 bichrome triangles.</li>
<li>The total number of distinct triangles is (6*5*4) / (3*2*1) = 20.</li>
</ul><p>Hence, there are at least 20 - 18 = 2 monochrome triangles.</p>
<p>Dijkstra's point is that by recognizing and exploiting the symmetries of the problem at hand, the proof becomes simpler and hence easier to conduct. The word "simpler" here refers to less case distinctions (and hence to "generality"). The word "easier" refers to the virtue that the proof has less of an invitation to visualization. (My <em></em>personal experience is that I have indeed had to draw much less in order to understand Dijkstra's proof compared with the first proof.)</p>
<p>To summarize in Dijkstra's own words:</p>
<blockquote><p>Being of equal or of different colour are the <span style="text-decoration: underline;">only</span> functions that are invariant under colour inversion --- note that, accordingly, in the last proof the colours themselves are not mentioned at all! --- ; furthermore somewhere the topology of the complete 6-graph has to be taken into account, hence the notion of a V, hence the mixed V. [...] Similarly the last proof fully maintains the symmetry between the nodes (to the extent that they too remain anonymous). Its final virtue is that it is much less of an invitation to visualization. <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD803.PDF">[EWD803, p.21]</a></p>
</blockquote>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Wed, 29 Feb 2012 15:51:58 +0000egdaylight86 at https://dijkstrascry.comhttps://dijkstrascry.com/node/86#commentsDijkstra's Elegance vs. Naur's Pluralism
https://dijkstrascry.com/node/84
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">November 1981</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>During the early 1960s, Dijkstra and Naur were much in sync with each other's research aspirations. They were, after all, <a href="/node/4">both involved in implementing and promoting the ALGOL60 programming language</a>. Dijkstra's 1970 `Notes on Structured Programming' was a pivotal point in their relationship, as described in <a href="/node/73">my interview with Naur</a>. From that point onwards, their research agendas diverged.</p>
<p>By November 1981, <a href="/node/80">Dijkstra had become interested in mathematical methodology</a>; he wanted to find an objective measure for simplicity, for ``mathematical elegance''. In his words:</p>
<blockquote><p>I have come to the opinion that some arguments are objectively simpler than others. [...]</p>
<p>[A]mong a great number of mathematical colleagues I found a much greater consensus about what was really elegant than they had suspected. <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD803.PDF">[EWD803, p.4]</a></p>
</blockquote>
<p>Naur, by contrast, believed a researcher should respect the multitude of personal styles in solving problems. Naur opposed those who claimed that there is one uniform way to conduct science, nor did he believe that the notion of ``mathematical elegance'' can be agreed upon, let alone be defined and measured.</p>
<p>The deeper difference between Dijkstra and Naur lies in the former's implicit acceptance and the latter's explicit rejection of Western philosophy. According to Naur, Dijkstra viewed mathematics and science as the only vehicles for true progress. But for Naur ``scientists'' are merely symbol chauvinists who firmly believe that mathematical structures prevail over material ones.</p>
<p>In November 1981, Dijkstra had just commenced with his quest:</p>
<blockquote><p>For the time being it suffices to capture mathematical elegance by the slogan ``short is beautiful''. <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD803.PDF">[EWD803, p.4]</a></p>
</blockquote>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Fri, 17 Feb 2012 09:51:26 +0000egdaylight84 at https://dijkstrascry.comhttps://dijkstrascry.com/node/84#commentsAn analogy between computer programs and mathematical proofs
https://dijkstrascry.com/node/80
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">November 1981</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>In 1961, Dijkstra made <a href="/node/75">an analogy between mathematical proofs and computer programs</a>. After noting the analogy, he took aspects from the field of mathematics and projected them onto his own profession of programming.</p>
<p>Twenty years later, Dijkstra still stood by the analogy. This time, however, he projected the lessons he had learned from programming methodology back onto mathematics. Dijkstra was thus, in 1981, keen on defining a mathematical methodology. In Dijkstra's words:</p>
<blockquote><p>I am relying on the analogy between programs and proofs, an analogy which is the inspiration behind my effort to transfer what programming methodology has taught us to mathematical methodology in general.</p>
</blockquote>
<p>To further clarify his research agenda, Dijkstra distantiated himself from dominant traditions in logic, philosophy, and mathematics. Dijkstra was not interested in formalisms for the sake of capturing the foundations of mathematics. Instead, he only wanted to use formal methods if they could help pragmatically; that is, if they could help in conducting mathematics itself.</p>
<p>Dijkstra knew that his unorthodox research agenda would be countered by dominant voices. He therefore stressed from the start that he did not expect others to share his interests.</p>
<blockquote><p>We are not prescribing the law to anybody, we are not even attempting to propose something, but have rules for ourselves.</p>
</blockquote>
<p class="MsoNormal">Source: <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD803.PDF">the first few pages of EWD 803</a>.</p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Tue, 17 Jan 2012 20:22:36 +0000egdaylight80 at https://dijkstrascry.comhttps://dijkstrascry.com/node/80#commentsTrip to Amsterdam, October 1981
https://dijkstrascry.com/node/79
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">26-29 October 1981</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>Dijkstra attended the four-day “International Symposium on Algorithmic Languages” in honor of Aad van Wijngaarden who was retiring as director of Amsterdam's `Mathematical Centre'. The symposium was held from Monday 26 October until Thursday 29 October 1981. Ershov and Turski also attended after having spent the weekend with Dijkstra at his home in Nuenen.</p>
<p>Dijkstra had been Van Wijngaarden's PhD student during the 1950s. By the end of that decade, Van Wijngaarden had lost his wife in a car accident. As a result, he became estranged from many friends and colleagues in later years. During the 1960s and later, Van Wijngaarden and Dijkstra became more distanced from each other, as the following 1981 description by Dijkstra of the aforementioned event illustrates:</p>
<blockquote><p>As a member of the Program Committee I knew that it would not be a very good conference; apparently the computing community had sensed this, for there were only about 125 participants. [...] The conference quite clearly suffered from the fact that it had been organised in honour of van Wijngaarden, who was sitting in the front row. A number of speakers really deserved to be torn apart, but the audience did not do it (or the chairman did not allow it) for fear of spoiling the fun for van Wijngaarden.</p>
</blockquote>
<p>Equally noteworthy is that Dijkstra praised Naur's talk at the symposium even though, <a href="/node/73">from Naur's point of view, their relationship had ceased to be friendly during the late 1960s and the early 1970s</a>. Based on similar observations that I have made from other sources, I am currently inclined to ascertain that Dijkstra did not share Naur's animosity.</p>
<p>Some other speakers at the symposium were R. Schild, B. Meyer, M. Broy, M. Sato, and J.C. Reynolds. The rest of the talks were according to Dijkstra not very good. Darlington's talk in particular was “totally unconvincing” to Dijkstra. This was <a href="/node/51">not the first time</a> that Dijkstra expressed such reservations.</p>
<p>Source: <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD805.PDF">EWD 805, written on 30 October 1981</a>.</p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Tue, 03 Jan 2012 16:33:07 +0000egdaylight79 at https://dijkstrascry.comhttps://dijkstrascry.com/node/79#commentsTrip to Scotland and Newcastle, September 1981
https://dijkstrascry.com/node/72
<section class="field field-name-field-histdate field-type-text field-label-inline clearfix view-mode-rss"><h2 class="field-label">Dated: </h2><div class="field-items"><div class="field-item even">31 August -- 15 September, 1981</div></div></section><div class="field field-name-body field-type-text-with-summary field-label-hidden view-mode-rss"><div class="field-items"><div class="field-item even" property="content:encoded"><p>In the late summer of 1981, Dijkstra gave several talks in Scotland and Newcastle. Here is an overview of his trip:</p>
<p>+ The Marine Hotel in North Berwick. The host was Mr. Hannah of Burroughs. The audience consisted of 10 men from various Burroughs plants in Europe. Dijkstra lectured for five successive days, between 6 and 7 hours per day. The "standard surprise" from the audience was that the universal quantification over the empty set yields true.</p>
<p>+ By train to Newcastle-upon-Tyne. The host was — as usual — Brian Randell. Dijkstra stayed in Randell's house for 9 days; Randell's two eldest children slept outside in a tent. In Newcastle, Dijkstra attended the 14th Joint International Seminar on the Teaching of Computing Science, which was devoted to Very Large Scale Integration. A summary in Dijkstra's words: "Much of the design process as shown to us seemed engineering in the worst possible sense of the word, viz. essentially by trial and error."</p>
<p>+ Off to Glasgow, to visit the Department of Computer Science of the university. The host was J. Cavouras. Dijkstra gave a talk on the presentation of programs for an audience of about 100 people.</p>
<p>+ Off to Edinburgh, to visit the Heriot-Watt University. The host was H. Davis. Dijkstra gave the same talk for an audience of about 75 people.</p>
<p>Source: <a href="http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD802.PDF">EWD 802</a></p>
</div></div></div><section class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above view-mode-rss"><h2 class="field-label">Tags: </h2><ul class="field-items"><li class="field-item even" rel="dc:subject"><a href="/taxonomy/term/10" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary80s</a></li></ul></section>Mon, 12 Sep 2011 11:34:20 +0000egdaylight72 at https://dijkstrascry.comhttps://dijkstrascry.com/node/72#comments