Dijkstra's Rallying Cry for Generalization - Category Mistakes
https://dijkstrascry.com/category-mistakes
Category mistakes by Dijkstra, Hoare, and others
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#comments`Plato and the Nerd,' Part 2a: Penrose et al.
https://dijkstrascry.com/Lee2a
<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">13 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>During the past seven years there have been only a handful of popularized books on engineering & science that I have read from cover to cover in less than a week. These books are listed here:</p>
<ol><li>Donald MacKenzie's <em>Mechanizing Proof: Computing, Risk, and Trust</em> [9]</li>
<li>Peter Naur's <em>Knowing and the Mystique of Logic and Rules</em> [10]</li>
<li>Timothy Colburn's <em>Philosophy and Computer Science</em> [2]</li>
<li>Matti Tedre's <em>The Science of Computing: Shaping a Discipline</em> [13]</li>
<li>Gilles Dowek's <em>Computation, Proof, Machine: Mathematics Enters a New Age</em> [4]</li>
</ol><p>A sixth and brand new item on my list of favorites is Edward A. Lee's <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), which I have <a href="http://www.dijkstrascry.com/Lee1">previously introduced here</a>.</p>
<p>Besides the aforementioned books, I also recall being inspired in the early 2000s by the writings of Douglas Hofstadter [7], James Gleick [6], Stephen Wolfram [15], and Roger Penrose [11]. (Obviously I needed more than a week to get through Wolfram's 1000+ pages.) I remember discussing Penrose's book in 2008 at the <em>Institute of Logic, Language, and Computation</em> of the University of Amsterdam. Surrounded by logicians, I was told that Penrose was considered a “crackpot” due to his allegedly ill-informed and opposing views on digital physics. Yet it was partly due to Penrose's book and his intriguing interpretation of Gödel's 1931 results, that I decided to enroll in 2007 in a Master of Logic program at the aforementioned institute in the first place.</p>
<p> </p>
<p><strong>PENROSE, WEGNER, BAETEN, NAUR, SUCHMAN</strong></p>
<p>Both Penrose and Lee oppose the widespread belief that everything is a digital computer, that the physical world is equivalent to software [8, p.169]. Unlike Penrose, Lee says that the physical world can nevertheless be fully explained using the known laws of physics; in Lee's own words:</p>
<blockquote><p>Penrose argues that the mind is not algorithmic and must be somehow exploiting hitherto not-understood properties of quantum physics. I am making a less radical argument, in that I argue that the mind is not digital and algorithmic even if it <span style="text-decoration: underline;"><em>can</em></span> be fully explained using the known laws of physics. [8, p.182, Lee's emphasis]</p>
</blockquote>
<p>Let me hasten to remark, especially for strong proponents of a rational metaphysical view to our digital world, that Lee does <em>not</em> claim in his 2017 book that he or anyone else for that matter has found a practical way to solve the Halting Problem. But, neither does Lee dismiss the prospect entirely nor should he if he wants to stay consistent with his philosophical stance. My interpretation (so far) of Lee's account is that some person, or some thing, can possibly accomplish the “impossible” in an unconventional way; i.e., without programming (in the common sense of the word) the incomputable function at hand.</p>
<p>More central to Lee's book is his observation that not every function needs to be describable in order to be useful in our daily lives [8, p.177]. For example, humans have no need “to measure or write down the distance” that their vehicles carry them “to get value of it” [8, p.177]. Discussing the matter in more general terms, Lee writes:</p>
<blockquote><p>The fact that computers do not and cannot deal with continuums in no way proves that there are no machines that <span style="text-decoration: underline;"><em>can</em></span> deal with continuums. [8, p.174, Lee's emphasis]</p>
</blockquote>
<p>A car is such a machine that deals with continuums: it can transport, say, a person from position <em>A</em> to position <em>B</em>, with both <em>A</em> and <em>B</em> denoting real numbers.</p>
<p>As Lee points out on page 146 in his book, Peter Wegner tried to convey a similar message two decades ago [14]. This was at a time when questioning the dominance of Turing-machine computations was much more tricky than it is today. Wegner received quite a backlash from — surprise! — theoretical computer scientists; see e.g., <a href="http://blog.computationalcomplexity.org/2006/07/principles-of-problem-solving-tcs.html">Lance Fortnow's 2006 blog post</a>. In 2015 I had my students study Wegner et al.'s writings and also comment in detail on <a href="http://www.dijkstrascry.com/StudentEssay">Jos Baeten's research on interactive computing</a>, i.e., research in which Baeten explicitly distinguishes between <em>information</em> and <em>computation</em> and where he builds up a more general theory of computation, more adequately called <em>executability theory</em>, which is based on Baeten et al.'s formal notion of a <em>reactive Turing machine</em> [1], not a classical Turing machine.</p>
<p>Coming back to Lee's <em>Plato and the Nerd</em>. Again, not every function needs to be describable in order to be useful. Lee provides several examples throughout his book, along with his example of the <em>balloon machine</em>. “Consider a simple balloon,” Lee writes,</p>
<blockquote><p>I can think of this balloon as a machine that outputs the circumference of a circle given its diameter. Suppose I inflate the balloon until it reaches a specific diameter d at its widest point. The balloon then exhibits a circumference at a cross-section at that widest point. The “input” to the machine is the diameter d, and the output is the circumference, which by the basic geometry of circles should come out to ∏ x d. If I inflate the machine to a diameter of one foot, it calculates ∏. [8, p.174]</p>
</blockquote>
<p>With this balloon machine, we could “insist on writing the circumference down as a decimal number on paper” — and, hence, attempt to make the function (concerning real numbers) describable after all — but then we “have already forced the problem into the realm of digital computers” [8, p.177]. Just to be clear: Lee takes little or no issue with classical computability theory. His main interests simply lie elsewhere: in the <em>complementarity</em> between humans and machines. Like Penrose and Wegner, Lee does not treat humans as machines or machines as humans. In Lee's words: “We can do many more useful things with computers that <em>complement</em> human capabilities” [8, p.236, original emphasis].</p>
<p>Lee's perspective is also similar to that of Lucy Suchman, a renowned researcher in computer-supported cooperative work. Both scholars question cognitive science's prime premise, that people act on the basis of symbolic representations, and both scholars question the general agreement in cognitive science that “cognition is not just potentially <em>like</em> computation; it literally <em>is</em> computational” [12, p.37, original emphasis].</p>
<p>Lee and Suchman's views align with those of the late Naur. Peter Naur's inspiration came largely from William James's <em>Psychology of Knowing</em>. Naur cites James extensively in his 1995 monograph <em>Knowing and The Mystique of Logic and Rules</em> [10]. For example, on page 12 in Naur's monograph, James is cited as follows:</p>
<blockquote><p>"Consciousness, then, does not appear to itself chopped up in bits. Such words as `chain' or `train' do not describe it fitly as it presents itself in the first instance. It is nothing jointed; it flows. A `river' or a `stream' are the metaphors by which it is most naturally described. <span style="text-decoration: underline;"><em>In talking of it hereafter, let us call it the stream of thought, of consciousness, or of subjective life</em>.</span>" [10, original emphasis]</p>
</blockquote>
<p>These words by James, endorsed by Naur, support Lee's exposition too. Indeed, besides the examples of the car and the balloon machine, Lee also discusses the brain. It too, as Lee expounds, can be viewed as an information-processing system that is far more likely to be a machine that deals with uncountable sets than it is to be a computer which solely deals with the countable world of computer science's most favorite mathematical objects — my paraphrasing from Lee [8, p.174].</p>
<p> </p>
<p><strong>MY FAVORITE QUESTION<br /></strong></p>
<p>I will continue to engage with Lee and other scholars in follow-up blog posts. There are many more themes in Lee's book that I want to discuss, I have barely scratched the surface. With that said, every now and then I wish to zoom in on my favorite philosophical question:</p>
<blockquote><p>1. What is a computer program?</p>
</blockquote>
<p>I have examined this question multiple times before; see, for example, my latest book <em>Turing Tales</em> [3] and my post on <a href="/node/152">flowcharts and the year 1973</a>. It was only when reading Lee's final chapter that I came to more fully understand his philosophical inclination (which I will elaborate on in another post). Addressing Question 1 is a prerequisite for attempting to answer the following <em>socially relevant</em> question:</p>
<blockquote><p>2. Will we (ever) be able to know, let alone convincingly demonstrate to others, that our software is bug free?</p>
</blockquote>
<p>I am, and not without hesitation, using the terms “computer program” in Question 1 and “software” in Question 2 as synonyms. I did the same in <a href="http://www.dijkstrascry.com/Lee1">my previous blog post</a> but anticipate having to make further refinements in the near future.</p>
<p>While reading Lee's book, I became more convinced that the distinction I make in Question 2 between “knowing” on the one hand and “convincingly demonstrating” or teaching something on the other hand is justified. A couple of months ago I would have considered the distinction to be void. (And I realize that epistemologists of cognition, such as James Fetzer, are probably well aware of this insight. I am currently not in a position to grasp the literature of Fetzer et al. [5].)</p>
<p>Again, I take Lee's exposition to imply the following: a human can “know” things that she cannot explain well or not at all. Consider, for instance, a reputable programmer who “knows” that her software is bug-free, yet is unable to convincingly demonstrate her “knowledge” to others. From Lee's perspective, the brains of humans (and thus of programmers) are useful information-processing machines which do “many things that we do not know to be Turing computation” [8, p.179].</p>
<p> </p>
<p><strong>REFERENCES<br /></strong></p>
<p><strong>[1]</strong> J.C.M. Baeten, B. Luttik, and P. van Tilburg. Reactive Turing machines. Information and Computation, 231:143-166, 2013.</p>
<p><strong>[2]</strong> T.R. Colburn. <em>Philosophy and Computer Science</em>. M.E. Sharpe, 2000.</p>
<p><strong>[3]</strong> E.G. Daylight. <em>Turing Tales</em>. Lonely Scholar, 2016.</p>
<p><strong>[4]</strong> G. Dowek. <em>Computation, Proof, Machine: Mathematics Enters a New Age</em>. Cambridge University Press, 2015.</p>
<p><strong>[5]</strong> J.H. Fetzer, editor. <em>Epistemology and Cognition</em>. Kluwer Academic Publishers, 1991.</p>
<p><strong>[6]</strong> J. Gleick. <em>Chaos: Making a New Science</em>. Penguin Books, 1987.</p>
<p><strong>[7]</strong> D. Hofstadter. <em>Gödel, Escher and Bach: An Eternal Golden Braid</em>. Basic Books, 1979.</p>
<p><strong>[8]</strong> E.A. Lee. <em>Plato and the Nerd: The Creative Partnership of Humans and Technology</em>. MIT Press, 2017.</p>
<p><strong>[9]</strong> D. MacKenzie. <em>Mechanizing Proof: Computing, Risk, and Trust</em>. MIT Press, 2004.</p>
<p><strong>[10]</strong> P. Naur. <em>Knowing and the Mystique of Logic and Rules</em>. Kluwer Academic Publishers, 1995. ISBN 0-7923-3680-1.</p>
<p><strong>[11]</strong> R. Penrose. <em>The Emperor's New Mind: Concerning Computers, Minds and the Laws of Physics</em>. Oxford University Press, 1989.</p>
<p><strong>[12]</strong> L.A. Suchman. <em>Human-Machine Reconfigurations: Plans and Situated Actions</em>. Cambridge University Press, second edition, 2007.</p>
<p><strong>[13]</strong> M. Tedre. <em>The Science of Computing: Shaping a Discipline</em>. Taylor and Francis, 2014.</p>
<p><strong>[14]</strong> P. Wegner. Why interaction is more powerful than algorithms. Communications of the ACM, 40(5), 1997.</p>
<p><strong>[15]</strong> S. Wolfram. <em>A New Kind of Science</em>. Wolfram Media, Inc., 2002.</p>
<p> </p>
<blockquote><p>“There is a tendency to rephrase every assertion about mind or brains in computational terms, even if it strains the vocabulary or requires the suspension of disbelief.”<br /><br />— John Daugman, cited by Edward A. Lee in [8, p.181]</p>
</blockquote>
<p> </p>
<p> </p>
<p><strong>CLARIFICATION added on 19 September 2017</strong></p>
<p>With this balloon machine, we could “insist on writing the circumference down as a decimal number on paper” — and, hence, attempt to make the function (concerning real numbers) describable after all — but then we “have already forced the problem into the realm of digital computers” [8, p.177].</p>
<p><strong>--></strong></p>
<p>With this balloon machine, we could (1) “insist on writing the circumference down as a decimal number on paper” [8, p.177] or (2) writing "a finite program that, in effect, describes the infinite sequence of digits that constitute ∏" [8, p.174] — and, hence, attempt (and in Case (2) successfully attempt) to make the function describable after all — but then we “have already forced the problem into the realm of digital computers” [8, p.177].</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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Wed, 13 Sep 2017 16:57:59 +0000egdaylight154 at https://dijkstrascry.comhttps://dijkstrascry.com/Lee2a#comments`Plato and the Nerd,' Part 1
https://dijkstrascry.com/Lee1
<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">3 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>Some computer scientists and software engineers write about the <em>history</em> of their fields. Others analyze and document the <em>philosophy</em> of their own discipline. In this latter regard, I am happy to announce the publication of Edward A. Lee's book on the philosophy of engineering:</p>
<blockquote><p><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)</p>
</blockquote>
<p>Lee's research at Berkeley centers on the role of models in the engineering of cyber-physical systems. That's what he has in common with Hermann Kopetz, Michael Jackson, David Parnas, and many others.</p>
<p>I have only ordered and not yet been able to read Lee's book. Lee and I have exchanged intellectual thoughts during the past few months, mostly in connection with the Kopetz Principle (see below). In the present post — Part 1 — I will look forward and speculate on likely topics in Lee's book. In a subsequent post — Part 2 — I will dive into specific sections of the book and discuss some technical topics from my vantage point.</p>
<p>For those interested in <em>original</em> views on the philosophy of computation, rest assured that Lee is not one of many who promotes the idea of digital physics. The physical world is not equivalent to software, according to Lee. The “likelihood is remote,” he writes on the book's website, “that nature has limited itself to only processes that conform with today's notion of digital computation.”</p>
<p>For those few — such as Peter Naur, Michael Jackson, and Dave Parnas — who are <em>well</em> aware that computer scientists typically mistake their favorite model for reality, rest assured. For, that message is precisely one of Lee's central points in his recent publications, talks, and in his 2017 book. Models are “invented not discovered,” Lee conveys on the book's website, “and it is the usefulness of models, not their truth, that gives them value.” This insight is much in line with <a href="http://www.lonelyscholar.com/node/7">Naur's views [1]</a>. Lee also writes that models “are best viewed as having a separate reality from the physical world, despite existing in the physical world.” This, too, is not unlike the ideas put forth by Brian Cantwell Smith [11], James Fetzer [5], and especially by <a href="http://www.lonelyscholar.com/jackson">Jackson [7]</a>. One aspect that definitely sets Lee apart from many of the other aforementioned scholars is his extensive expertise in physics and engineering. So, at the very least I expect Lee's 2017 book to be refreshing. I anticipate encountering arguments that <em>complement</em> those provided in the secondary literature, if not shed new light with unmatched technical precision. (For example, <a href="https://ptolemy.eecs.berkeley.edu/~eal/research.html">Lee's research</a> on determinism, concurrency, and on timed systems is definitely new to me. And I personally look forward to examining how Lee reasons about undecidability in Chapter 8 of his book.)</p>
<p>Finally, for those of us who are highly skeptical about the Internet of Moving Things, it might be worth our while to examine Lee's seemingly optimistic account in this regard. On the book's website, Lee argues that</p>
<blockquote><p>the pace of technological progress in our current culture is more limited by our human inability to assimilate new paradigms than by any physical limitations of the technology.</p>
</blockquote>
<p>I am prepared to scrutinize Lee's thoughts on this matter because I personally think that there <em>are</em> systems that <em>are</em> simply <em>not</em> makeable. (I am currently not in a position to thoroughly judge whether Lee would agree or disagree with my own take on this topic.) For example, today in Belgian newspapers: thousands of deployed pacemakers need to be upgraded as soon as possible due to a security vulnerability. That really is a déjà vu for me. (I have raised similar <a href="/DroneTuringComplete">concerns pertaining to automated cars, drones, smart phones, and nuke subs</a>.) If I were to carry a pacemaker, I would prefer it to be one that is <em>not</em> connected to a network, even if that would mean that I would have to pay more for such allegedly outdated technology. Software realists know that the next generation of pacemakers will <em>still</em> contain security vulnerabilities; it is only a matter of time before someone discovers them. Surely, there must be more people who share my frustration with this techno hype. (Indeed, fortunately there are policy makers who do listen to techno skeptics. I am referring to the Dutch elections held earlier this year, <a href="/zeppelin">as reported briefly here</a>.)</p>
<p>So, I am eager to find out what Lee's stance is on the viability of having a humanly safe Internet of Moving Things. Specifically, does Lee address, directly or indirectly, the following fundamental question?</p>
<blockquote><p>Will we (ever) be able to know, let alone convincingly demonstrate to others, that our software is bug free?</p>
</blockquote>
<p>If we will never achieve this goal, then neither can we guarantee that our software is completely secure. For, even a bug-free C program can be vulnerable to a malicious hacker [10, Sec.IV]. In my own words:</p>
<blockquote><p><strong>Bug-free software is a necessary, but not a sufficient, condition for having a secure </strong><strong>— and, hence, a humanly safe </strong><strong>— cyber-physical system. </strong></p>
</blockquote>
<p>At the end of the day it is all about <em>human safety</em>, not correctness, nor security. I don't mind having bugs in a text editor or an unmanned Mars Lander. But I will mind the bugs in fast moving objects (such as drones and automated vehicles) that society at large will use on a daily basis, because those bugs can have a detrimental effect on <em>human safety</em>.<strong> <br /></strong></p>
<p>There are <em>laws</em> for software engineering that have yet to be widely disseminated and I consider the previous bold-faced passage to convey one such law. I want to find out whether Lee shares my inclination and realism, because being a lonely scholar only gets me so far.<strong> </strong></p>
<p>In the rest of the present post I will focus on the role of models, as perceived by Lee and like-minded researchers and starting with Naur.</p>
<p> </p>
<p><strong>PETER NAUR</strong></p>
<p>In 2011 I interviewed Peter Naur at his home in Denmark. Naur's criticism for formal methods was two-fold:<strong><br /></strong></p>
<ol><li>His plea for pluralism: a computer professional should not dogmatically advocate a formal method and require others to use it in their own work. </li>
<li>Naur's insistence to distinguish between models on the one hand and the things being modeled on the other hand:<strong> </strong></li>
</ol><p style="padding-left: 60px;">A model of the structure of a molecule is just one kind of description of the substance under investigation, well known to ignore certain aspects of the actual substance .... [1, p.86]</p>
<p style="padding-left: 60px;">Descriptions are not true, never, they are more or less adequate. That's the best they can offer. [1, p.86]</p>
<p>Continuing on my quest to understand the history of formal methods in computer science, I also interviewed Michael Jackson.</p>
<p> </p>
<p><strong>MICHAEL JACKSON</strong></p>
<p>It is Jackson's reversal of Dijkstra's famous sentence, which I find to be most rewarding:</p>
<blockquote><p>[P]rogram testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.<br />— Dijkstra [3].</p>
<p><br />To turn Dijkstra’s famous observation on its head, we should say that in a cyber-physical system, where the computer's purpose is to exercise control over the material world, formal reasoning can demonstrate the presence of error, but never its absence.<br />— Jackson [7, p.67]. <strong><br /></strong></p>
</blockquote>
<p>Jackson has been inspired by Cantwell Smith's famous paper, `The Limits of Correctness' [11], and it should also be noted for the sake of completeness, that Jackson's original words appeared in 1998:</p>
<blockquote><p>Dijkstra famously observed that in the pursuit of program correctness “testing can show the presence of errors but not their absence”. In the pursuit of well-engineered descriptions of the real world we should recognise — and every student of software engineering should be taught — that <span style="text-decoration: underline;"><em>formalisation can show the presence of description errors, but not their absence</em></span>. [6, my emphasis]</p>
</blockquote>
<p> </p>
<p><strong>HERMANN KOPETZ</strong></p>
<p>More recently, and thanks to a pointer provided by Jackson, I came across the writings and YouTube videos of Edward A. Lee. Specifically, Lee conveyed the revealing “Kopetz Principle” in his 2012 talk, entitled: <a href="https://www.youtube.com/watch?v=O_0FDUsFXaY">`Verifying Real-Time Software is Not Reasonable (Today).'</a> Indeed, 15 minutes into his talk, Lee provides the following text:<strong> </strong></p>
<blockquote><p><strong>The Kopetz Principle</strong></p>
<p>Many (predictive) properties that we assert about systems (determinism, timeliness, reliability) are in fact not properties of an <em>implemented</em> system, but rather properties of a <em>model</em> of the system.<br /><br />We can make definitive statements about <em>models</em>, from which we can <em>infer</em> properties of system realizations. The validity of this inference depends on <em>model fidelity</em>, which is always approximate.</p>
</blockquote>
<p>This passage is a result of Lee paraphrasing another expert in real-time software: Hermann Kopetz. Some 45 seconds later, Lee comments on formal verification in particular:</p>
<blockquote><p>The proofs in verification are not proofs about the system but about a model of the system. The usefulness of these proofs depends on the model fidelity. The model is always an approximation. [This is my paraphrased version of Lee's oral comments.]</p>
</blockquote>
<p>Finally, and unsurprisingly, Lee also disseminates these insights via his research papers. For example, he insists that <em>a C computer program is a <span style="text-decoration: underline;">model</span></em> too and <em>not</em> a system realization [8, p.4839]. The question I have, and which I will keep in the back of my mind while reading Lee's 2017 book, is whether that <span style="text-decoration: underline;"><em>model</em></span> is a mathematical model and, if so, what type of mathematical model. (I, myself, take <em>a C computer program</em> to be a non-mathematical model and, specifically, a technical artefact [2], following Raymond Turner [12]. That artefact can, of course, be mathematically modeled in various ways, resulting in multiple mathematical models of the <em>C computer program</em> at hand.)</p>
<p> </p>
<p><strong>DAVID PARNAS</strong></p>
<p>Mistaking the model for reality is also what Parnas is concerned about [2, p.8]. Rather than verify properties of an actual program, computer scientists are examining models of programs [2, p.100]. That, again, is very much in line with the Kopetz Principle. Moreover, last week I came across Parnas’s article `The use of mathematics in software quality assurance’ [9]. Especially page 14 is to the point. Parnas warns his readers to use a model with great care: “the user must always be aware that information obtained by analyzing the model might not apply to the actual product.” Likewise:<strong> </strong></p>
<blockquote><p>Most of the many published proofs of programs are actually proofs about models of programs, models that ignore the very properties of digital computers that cause many of the `bugs’ we are trying to eliminate. [9]</p>
</blockquote>
<p>Again, these ideas can already be found to some extent in the writings of Cantwell Smith [11], Fetzer [4,5], and others, but Parnas is zooming in on the Formal Methods community and is writing about formal verification. That's why his writings, now adjoined with <a href="http://www.platoandthenerd.org/index.html">Lee's 2017 book</a>, will probably remain on my desk for the years to come.</p>
<p> </p>
<p><strong>REFERENCES</strong></p>
<p><strong>[1]</strong> E.G. Daylight. <em>Pluralism in Software Engineering: Turing Award Winner Peter Naur Explains</em>. Lonely Scholar, 2011.<br /><strong>[2]</strong> E.G. Daylight. <a href="https://www.amazon.com/dp/9491386069"><em>Turing Tales</em></a>. Lonely Scholar, 2016.<br /><strong>[3]</strong> E.W. Dijkstra. The humble programmer. Communications of the ACM, 15(10):859-866, October 1972.<br /><strong>[4]</strong> J.H. Fetzer. Program verification: The very idea. Communications of the ACM, 31(9):1048-1063, 1988.<br /><strong>[5]</strong> J.H. Fetzer. The role of models in computer science. The Monist, 82(1):20-36, 1999.<br /><strong>[6]</strong> M. Jackson. Defining a discipline of description. IEEE Software, 15(5):14-17, September/October 1998.<br /><strong>[7]</strong> M.A. Jackson and E.G. Daylight. <em>Formalism and Intuition in Software Development</em>. Lonely Scholar, 2015.<br /><strong>[8]</strong> E.A. Lee. The past, present and future of cyber-physical systems: A focus on models. Sensors, 15:4837-4869, 2015.<br /><strong>[9]</strong> D.L. Parnas. The use of mathematics in software quality assurance. Frontiers of Computer Science in China, 6(1):3-16, 2012.<br /><strong>[10]</strong> F. Piessens and I. Verbauwhede. Software security: Vulnerabilities and countermeasures for two attacker models. In Design, Automation & Test in Europe Conference & Exhibition, Dresden, Germany, pages 990-999, 2016.<br /><strong>[11]</strong> B.C. Smith. The limits of correctness. ACM SIGCAS Computers and Society, 14,15:18-26, January 1985.<br /><strong>[12]</strong> R. Turner. Programming languages as technical artefacts. Philosophy and Technology, 27(3):377-397, 2014.<strong><br /></strong></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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li><li class="field-item odd" rel="dc:subject"><a href="/taxonomy/term/17" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Self-Driving Cars</a></li></ul></section>Sun, 03 Sep 2017 14:45:57 +0000egdaylight153 at https://dijkstrascry.comhttps://dijkstrascry.com/Lee1#commentsEnsmenger & Flowcharts
https://dijkstrascry.com/node/152
<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">8 July 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>One of the questions that keeps me awake (during the day) is the following one:</p>
<blockquote><p>What did a “computer program” mean to Actor X in 1973?</p>
</blockquote>
<p>For example, both Christopher Strachey and Edsger Dijkstra viewed a “computer program” as a mathematical object, albeit of a very different kind [1]. (A decade or more earlier, both men did not associate computer programs with mathematical objects <em>pur sang</em>). But what about large parts of the North American computer industry in 1973? How did actors in this field view a “computer program” in 1973?</p>
<p>Nathan Ensmenger's talk on flowcharts, which he gave on July 6th, 2017, at Siegen University [2], sheds light on this very question. Ensmenger made several points, most of them can be found in his article `The Multiple Meanings of a Flowchart' [3]. What struck me most is the following observation: in the 1970s many programmers in the USA were making an analogy between flowcharts and blueprints on the one hand, and between computer programs and buildings on the other hand. I call this development the “flowchart-as-blueprint” analogy, using Ensmenger's terminology.</p>
<p>My thoughts, so far, can be summarized as follows:</p>
<ul><li>In the early 1970s, <em>academics</em>, such as Strachey, Hoare, McCarthy, Dijkstra (*), eschewed flowcharts and appropriated the term “computer program” to mean a mathematical object of some kind. (Specifically, the <em>program text</em> had a formal syntax and the quest for a formal semantics had long begun.)</li>
<li>By contrast, many people in the <em>computer industry</em> compared, or continued to compare, a “computer program” with a concrete physical object, such as a building. They had flowcharts in order to reason <em>abstractly</em> about their computer programs (at least in principal).</li>
</ul><p>To illustrate the last item, I borrow Ensmenger's citation of McInery & Vallee's 1973 statement:</p>
<blockquote><p>Flowcharts are to programmers as blueprints are to engineers. Before a construction engineer begins in building, he draws detailed plans from which to work. These plans are called blueprints.</p>
<p> </p>
<p>Before a programmer begins to code a program into one of the computer languages (such as COBOL or ALGOL), you must have a detailed blueprint of the steps to follow. The blueprint is known as a flowchart.</p>
<p> </p>
<p>Engineers and construction foremen must be able to draw and read blueprints. Programmers must be able to draw and read flowcharts. Flowcharting is a necessary and basic skill for all programmers. [6]</p>
</blockquote>
<p>So, Ensmenger addresses the question “What is a flowchart?”, and by doing so he sheds light on the question “What is a computer program?” (A flowchart is like a blueprint, and a computer program is like a building.) As a result we gain a better understanding of what software entailed in large parts of North American industry in the 1970s.</p>
<p>Also in his talk, but not in his paper, Ensmenger referred to some work of Friedrich Bauer. Now, Bauer was first and foremost an academic <em>software engineer</em>, not a computer specialist working solely in industry, and even less an academic computer scientist. In fact, as editor of the 1973 book <em>Software Engineering: An Advanced Course</em> [4], he used both the preface and an appendix to explain where software engineering as an academic discipline had to belong. “Software engineering,” he wrote on page 523, is “that part of computer science, which is too difficult for the computer scientist.” The next historical question, then, is:</p>
<blockquote><p>What did a “computer program” mean to F.L. Bauer in 1973?</p>
</blockquote>
<p>Did Bauer subscribe to the flowchart-as-blueprint analogy? That is, did he continue to view a computer program as mostly (if not purely) physical, as he had presumably done himself in the very early days of computing? Or did he follow the formal methodists in computer science by (essentially) <em>equating</em> a computer program with a mathematical object? (This conceptual slip of the tongue, or conceptual oversight, made by formal methodists, is the controversial topic of my recent book [1].)</p>
<p>The answer is “no” on all accounts. For Bauer “software” — which I take here to be <em>at least a bit</em> synonymous with “computer program” — is neither physical, nor solely mathematical. In Bauer's words:</p>
<blockquote><p>[S]oftware is not a physical object, it is non-material.</p>
<p> <br />It needs physical objects as carriers only, and it is altogether unspecific about the carrier.</p>
<p> <br />Since the material is cheap — paper as a carrier is sufficient [...]</p>
<p> <br />[S]oftware is an abstract web, comparable to mathematical tissue, but it is a process and in so far very different from most of usual mathematics, too. [4, p. 524-525]</p>
</blockquote>
<p>Having provided this rather unique choice of words, my educated guess, nevertheless, is that Bauer was only one of many to characterize software as a <em>process</em>. But, reflecting and carefully placing software not entirely among abstract objects (mathematics), nor in the category of physical objects (civil engineering), seems to have been much less common.(**) In retrospect, then, and with a bit of an exaggeration, I take Bauer's 1973 viewpoint to be a precursor of Raymond Turner's recent analysis in which he introduces a category of <em>technical artefacts</em> in order to give “computer programs” a proper philosophical treatment [5].</p>
<p>As a brain-washed academic myself (loving mathematics four days a week instead of three), my reading of Ensmenger's historical exposition reconfirms that treating computer programs as non-mathematical entities was not exceptional at all, and this was not so long time ago either. This non-mathematical view has presumably remained dominant in industry. I believe that even the flowchart, which was perceived as abstract (and akin to a “mathematical algorithm,” using Ensmenger's terminology once again), was mostly not associated with mathematics proper in any direct way, at least not in industry.</p>
<p>In sum, we already have three different 1973 viewpoints on what a “computer program” entails:</p>
<ol><li>Strachey, Dijkstra, and other computer scientists</li>
<li>USA industry</li>
<li>Bauer and other software engineers</li>
</ol><p>(There were more viewpoints, and they are also very much present today.)</p>
<p>Why all this fuss about the definition of a <em>computer program</em> or, if you like, the underpinnings of <em>software</em>? Just like Bauer (illustrated above) and Strachey (not illustrated here), I, too, want to get a firm grip on the foundations of programming, but preferably programming <em>tout court</em> (and not just programming fundamentals of one particular paradigm), and partly for the sake of computer science itself. Clearly, these philosophical foundations do <em>not</em> yet exist, contrary to popular belief. Or, if they do, as in the form of Turner's work, they have yet to be widely disseminated and scrutinized.</p>
<p> </p>
<hr /><p><strong>FOOTNOTES</strong></p>
<p>(*) <a href="/node/104">Dijkstra still called himself a “software engineer” in 1972, but was in the process of becoming a “computer scientist,” in accordance with the (shifting) definitions of Dijkstra, Reynolds, and the like.</a></p>
<p>(**) Bauer's 1973 view is still highly controversial today: many academics place software in the category of mathematical objects, as I have written about in my recent book [1], and as I have been told by more than one careful reviewer.<strong> </strong></p>
<p> </p>
<p><strong>REFERENCES</strong></p>
<ul><li>[1] E.G. Daylight, <a href="http://www.lonelyscholar.com/turingtales"><em>Turing Tales</em></a>, Lonely Scholar, December 2016.</li>
<li>[2] Conference at Siegen University, <a href="http://www.socialstudiesof.info/computingiswork/"><em>Computing is Work!</em></a>, July 6-8, 2017.</li>
<li>[3] N. Ensmenger, <a href="http://thecomputerboys.com/?p=743">`The Multiple Meanings of a Flowchart,'</a> Information & Culture: A Journal of History, Vol. 51, Nr. 3, 2016.</li>
<li>[4] F.L. Bauer (ed.), <em>Software Engineering: An Advanced Course</em>, Springer-Verlag, 1973.</li>
<li>[5] R. Turner, `Programming Languages as Technical Artefacts.' In: <em>Philosophy and Technology</em>, 27.3 (2014).</li>
<li>[6] Thomas McInerney and Andre Vallee, <em>A Student’s Guide to Flowcharting</em> (Englewood Cliffs, NJ: Prentice-Hall, 1973.)</li>
</ul><p> </p>
<blockquote><p>"We are captured by a historic tradition that sees programs as mathematical functions and programming as the central practice for translating these functions into working systems." — Peter J. Denning in 2004</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/9" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">diary70s</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, 08 Jul 2017 13:28:15 +0000egdaylight152 at https://dijkstrascry.comhttps://dijkstrascry.com/node/152#commentsMichelle Obama vs. the Gatekeeper
https://dijkstrascry.com/node/145
<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">15 October 2016</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>Category mistakes and incomputability claims seem to go hand in hand. I have given one modern example in connection with <a href="/node/140">programming languages and Michael Hicks</a> and another one directly concerning <a href="/node/143">the diagonal argument</a>. In the present blog post I shall give one more example, based on an excerpt from my rejected POPL paper entitled: `Category Mistakes in Computer Science at Large.' Specifically, I shall zoom in on the “code improvement problem,” as discussed by Albert R. Meyer and Dennis M. Ritchie in their 1967 paper `The complexity of loop programs' [33].</p>
<p> </p>
<p><strong>Terminology</strong></p>
<p>I distinguish between two abstractions:</p>
<ul><li>abstraction A_{I}^{pos}, which allows for the representation of arbitrary large positive integers, and</li>
<li>abstraction A_{R}, which allows for the representation of infinite precision real numbers.</li>
</ul><p>I use the term “programming language” as an abbreviation for “computer programming language” and always write “mathematical programming language” in full.<strong> </strong></p>
<p><strong><br /></strong></p>
<p><strong>Extract from my Rejected POPL Paper: “Flawed Incomputability Claims”</strong></p>
<p>Let us turn to what I take to be flawed incomputability claims in the literature. Meyer & Ritchie's 1967 paper, for instance, is not solely about FORTRAN programs and LOOP programs, but, more generally, about the industrial “code improvement problem.” Is it possible to automatically improve the assembly code of a corresponding FORTRAN program? — that's the central question in the introduction of their paper. Citing from their introduction:</p>
<blockquote><p>[C]onsider the problem of improving assembly code. Compilers for languages like FORTRAN and MAD typically check the code of an assembled program for obvious inefficiencies — say, two “clear and add” instructions in a row — and then produce edited programs which are shorter and faster than the original. [33, p.465, my emphasis]</p>
</blockquote>
<p>As this excerpt shows, the authors specifically referred to the [computer] programming languages FORTRAN and MAD [and not to mathematical programming languages]. So, clearly, a “program” here refers to a computer program, not to a mathematical object.</p>
<p>To get a mathematical grip on the industrial “code improvement problem,” Meyer & Ritchie resorted to the theory of computability (and the theory of primitive recursive functions in the rest of their paper). Continuing with their introduction:</p>
<blockquote><p>From the theory of computability one can conclude quite properly that no code improving algorithm can work all the time. There is always a <strong>program</strong> which can be improved in ways that no particular improvement algorithm can detect, so no such algorithm can be perfect. [33, p.465, my emphasis]</p>
</blockquote>
<p>Here we see Meyer & Ritchie refer to the undecidability of the halting problem. The implication is that a “program” now refers to a mathematical object and, specifically, to a “Turing machine” (see the second footnote in their paper for a confirmation). In other words, a “program” here does not refer to, say, a finite state machine, and it definitely does not refer to a program residing in a computer.</p>
<p>Meyer & Ritchie subsequently conveyed some common wisdom from the theory of computation. It is possible to decide the halting problem for specific subsets of Turing machines(*); that is, even though the halting problem is undecidable in general, modeling computer programs as Turing machines can still lead to practical tools. (A modern example in this context is the work of Byron Cook et al. [9], which accepts both A_{I}^{pos} and A_{R}.) In their own words, regarding their code improvement problem:</p>
<blockquote><p>But the non-existence of a perfect algorithm is not much of an obstacle in the practical problem of finding an algorithm to improve large classes of common <strong>programs</strong>. [33, p.465, my emphasis]</p>
</blockquote>
<p>Here the word “program” thus still refers to a “Turing machine.”</p>
<p>My analysis so far shows that Meyer & Ritchie conflated their computer programs and their mathematical programs. Furthermore, Meyer & Ritchie only considered models of computation that comply with fundamental abstraction A_{I}^{pos}, namely that any variable V can represent an arbitrary large positive integer. Specifically, they only considered a mathematical program as synonymous to either a Turing-machine program (i.e., a partially computable function) or a LOOP program (i.e., a primitive recursive function). But, as we have seen, there are also models of computation that do not comply with abstraction A_{I}^{pos}.</p>
<p>Based on their mathematical analysis, Meyer & Ritchie ended their paper with an impossibility claim about computing practice:</p>
<blockquote><p>If an “improvement” of the code of a <strong>program</strong> is defined as a reduction in depth of loops or number of instructions (without an increase in running time), then the proof of [the undecidability result expressed in] Theorem 6 also reveals that there can be no perfect code improvement algorithm. Thus the code improvement problem, which we noted in the introduction was undecidable for <strong>programs</strong> in general, is still undecidable for the more restricted class of Loop <strong>programs</strong>. [33, p.469, my emphasis]</p>
</blockquote>
<p>A purely mathematical — and, hence, valid — interpretation of Meyer & Ritchie's findings would amount to stating that the theoretical variant of the “code improvement problem” is not only undecidable for Turing-machine programs in general, but also for the more restricted class of LOOP programs. My disagreement has to do with the conflation made between the theoretical variant of the “code improvement problem” and the actual, industrial “code improvement problem.” It is the latter which is “noted in the introduction” of their paper in connection with FORTRAN and MAD, <em>not</em> the former.</p>
<p>As a result then — and now a specific technical contribution of my analysis follows — it is still very well possible that somebody <em>does</em> end up defining the improvement of the code of a FORTRAN program as a reduction in depth of loops or number of instructions without an increase in running time and yet still obtains a perfect code improvement algorithm for these computer programs. (The adjective “perfect” can, however, only be quantified in a well-defined mathematical setting.) Meyer & Ritchie's paper only indicates that the person who aspires doing so will have to resort to a model of computation that does not comply with abstraction A_{I}^{pos}.</p>
<p><strong>Footnote</strong> (*) I thank a reviewer for making the following observation: the Timed Automata model is another example that does not rely on finite abstractions and yet is complete and decidable.</p>
<p> </p>
<p><strong>Michelle Obama Comes to the Rescue</strong></p>
<p>That, then, was another excerpt from my rejected POPL paper. Perhaps the POPL Gatekeeper agrees with my analysis — because s/he says it “is only a recapitulation of dialogues familiar to everyone working in verification and related areas” — and perhaps s/he therefore considers my specific technical contribution to be trivial. I believe my analysis is very trivial indeed, but only in retrospect. Meyer and Ritchie's main claim is similar to that of <a href="/CategoryMistakes">Dr. X</a> who, briefly put, says that he has mathematically <em>proved</em> that certain <em>systems</em> cannot be <em>engineered</em>. And that incorrect claim, in turn, shows some resemblance to <a href="/node/140">Michael Hicks's views</a>.</p>
<p>I honestly don't know whether the POPL Gatekeeper is <em>really</em> convinced that Meyer and Ritchie have incorrectly projected their theoretical findings onto programming practice. Here's what the POPL Gatekeeper has to say in his/her own words about my rejected paper:</p>
<blockquote><p>I believe the main points of this paper are already widely agreed-upon in the POPL community and are used appropriately throughout the literature, even in the (relatively recent) papers that are quoted as evidence to the contrary. What I expect is that the author of this paper is an outsider to the POPL community and has misunderstood its conventions for writing about formalism.</p>
</blockquote>
<p>The POPL Gatekeeper has made a <a href="/node/142">similar remark about Dave Parnas</a> who had the audacity to scrutinize the writings of some honorable POPL members in the Communications of the ACM.</p>
<blockquote><p>[Continued:] The conclusions may be interesting as a data point on how outsiders may misinterpret formal-methods papers, though it's not clear the situation here is any worse than it is for the average technical field.</p>
</blockquote>
<p>Four quick points:</p>
<ol><li>Is the Gatekeeper suggesting that I first research whether “the situation” is worse in computer science than in other disciplines and that I then come back to the POPL gate if (and only if) the answer is affirmative? (My educated guess is that researchers in more mature disciplines make less category mistakes.) At least the Gatekeeper is implicitly acknowledging that “the situation” can be improved. That's a start.</li>
<li>A researcher who does consistently distinguish between the model and the technical artefact is always preferable to someone who conflates the two. Check out the <a href="/node/142">Parnas-Chaudhuri exchange</a> and judge for yourself. </li>
<li>I'm afraid I'm not the kind of outsider the Gatekeeper was expecting. I talk to formal methodists every single day. I even used to be a symbol chauvinist but at some point in my career I met people who were asking the right questions.</li>
<li>I'm sure many of my findings are obvious to the Gatekeeper but I'm also certain that s/he has not grasped all implications (<a href="/node/144">see this</a>). </li>
</ol><p>Continuing with the Gatekeeper's words:</p>
<blockquote><p>I think this paper should not be accepted, because it is only a recapitulation of dialogues familiar to everyone working in verification and related areas, and yet at the same time the paper fails to "do no harm," taking quotes out of context to accuse researchers of confusion.</p>
</blockquote>
<p>As Michelle Obama has said recently, “when they go low, we go high.”</p>
<blockquote><p>[Continued:] As a convincing paper should, this one presents evidence for its thesis that the credo above is *not* already in wide use, explaining how research papers are giving misleading impressions about what their results prove. The evidence is entirely in the form of historical anecdotes and quotes from a handful of papers.</p>
</blockquote>
<p>Historical anecdotes? A handful of papers? Is the Gatekeeper suggesting that I first find many more papers (which really is no difficulty at all) and that I then come back to knock on the POPL gate? What about all the <em>other</em> examples presented in the books of <a href="https://www.amazon.com/Philosophy-Computer-Science-Bureaucarcies-Administration/dp/156324991X">Timothy Colburn</a> and <a href="https://mitpress.mit.edu/books/mechanizing-proof">Donald MacKenzie</a> — books cited in my paper? Moreover, almost all articles discussed in my rejected POPL paper are authored by prominent computer scientists.</p>
<blockquote><p>[Continued:] There are conventions for how such papers are written and what is assumed about their contexts. The author of this paper seems to misunderstand the conventions, leading to sightings of fundamental confusions where none exist.</p>
</blockquote>
<p>Fortunately I belong to a second — or even a third — generation of software scholars who doesn't buy this rhetoric. I stand on the shoulders of James Fetzer, Peter Naur, Timothy Colburn and others who have already made complaints similar to those that I am making here. My small contribution here is that I am also</p>
<ol><li>discussing technical claims pertaining to computability theory,</li>
<li>following <a href="/node/139">Raymond Turner's</a> very recent publications about <em>technical artefacts</em>, and </li>
<li>using primarily POPL case studies in an attempt to reach out to the POPL community. </li>
</ol><blockquote><p>[Continued:] At most, these new observations call for considering *educational* strategies for informing a broader audience about these conventions; researchers in the field are already well aware of them and draw the correct conclusions from papers.</p>
</blockquote>
<p>So now the POPL Gatekeeper is at least admitting <em>some</em>thing. My clarifications are potentially beneficial to educators and outsiders; i.e., researchers who do not belong to the elite. I'm afraid the last sentence in the previous quote is false and, as I've explained before, I don't have any reason to believe that the POPL Gatekeeper actually understands the implications of <em>consistently</em> distinguishing between computer programs and mathematical programs. S/he has, remember, <a href="/node/142">sidestepped my observation</a> that multiple POPL members still tell me that it *is* possible to fully verify a digital *system*.</p>
<p> </p>
<p><strong>References</strong></p>
<p>[9] B. Cook, A. Podelski, and A. Rybalchenko. Proving program termination. Communications of the ACM, 54(5):88–98, May 2011.<br />[33] A. Meyer and D. Ritchie. The complexity of loop programs. In Proceedings of the ACM National Meeting, pages 465–469, 1967.</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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Sat, 15 Oct 2016 17:26:40 +0000egdaylight145 at https://dijkstrascry.comhttps://dijkstrascry.com/node/145#commentsMarvin Minsky and the Gatekeeper
https://dijkstrascry.com/node/144
<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">11 October 2016</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>A recurring theme in my blog posts is the appropriation of the term “computer program” by Dijkstra and other researchers. The “computer program” concept has acquired at least four different meanings during the course of history. It can refer to:</p>
<ol><li>a technological object à la Maurice Wilkes in 1950 and Dave Parnas in 2012,</li>
<li>a mathematical object of finite capacity à la Edsger Dijkstra in 1973,</li>
<li>a mathematical (Turing-machine) object of infinite size à la Christopher Strachey in 1973, and </li>
<li>a model of the real world that is not a logico-mathematical construction à la Peter Naur in 1985 and Michael Jackson today. </li>
</ol><p>With regard to Dijkstra and Strachey, see my <a href="http://www.dijkstrascry.com/infinite">blog post from March 2013</a>. For Naur's views, see <a href="http://www.lonelyscholar.com/node/7">my oral history</a> with him and, likewise, see <a href="http://www.dijkstrascry.com/MichaelJackson">my interview with Jackson</a>. (Finally, there is of course <a href="/node/139">Raymond Turner's philosophical perspective</a>: to view a “computer program” as a technical artefact, which is not quite the same as Viewpoint 1.)</p>
<p>What I find so vexing is that computer scientists did not consistently follow one interpretation in their writings. Marvin Minsky, for example, used the word “program” on page 25 in his 1967 book, <em>Computation: Finite and Infinite Machines</em> [8], to refer to data and instructions that fit in a real, finite memory of a physical computer. On page 153, by contrast, the very same word refers to a mathematical object of “unlimited storage capacity,” akin to a Turing machine. Likewise, Tony Hoare consistently used the word “computer” in 1969 to refer to a real physical device but in his 1972 paper the very same word sometimes refers to a finite, physical device and sometimes to a mathematical abstraction in which “infinite computations” can arise [4].</p>
<p>In sum, historical actors did not always explicitly distinguish between real objects and their models, let alone between all four aforementioned meanings of a “computer program.” In the words of an eminent scholar, “epistemic pluralism is a major feature of emerging fields” [1] and I have no reason to believe that computer science is any different.</p>
<p>In the next section I present an extract from my rejected POPL paper, pertaining to Minsky's reception of the halting problem. Again, it is the categorical distinction between a mathematical program and a computer program that I wish to emphasize, not to mention the fact that a computer program can be modeled with <em>multiple</em> mathematical programs. Minsky places a “computation system” and a “Turing machine” in the same category. That's fine as long as a computation system denotes a mathematical object. But, later on it becomes clear that he is talking about electronic computers.</p>
<p> </p>
<p><strong>Extract from my Rejected POPL Paper: “Marvin Minsky, 1967”</strong></p>
<p>That all being said and done, the anonymous referees [from the CACM] whom I have cited at length [in a previous part of my rejected POPL paper] are in good company for they have history on their side. In 1967 Marvin Minsky reasoned similarly in his influential book <em>Computation: Finite and Infinite Machines</em>, as the following excerpt illustrates:</p>
<blockquote><p>The unsolvability of the halting problem can be similarly demonstrated for any computation system (rather than just Turing machines) which can suitably manipulate data and interpret them as instructions.<br />In particular, it is impossible to devise a uniform procedure, or computer <strong>program</strong>, which can look at any computer <strong>program</strong> and decide whether or not that <strong>program</strong> will ever terminate. [8, my emphasis]</p>
</blockquote>
<p>How do we interpret Minsky's wordings? Does a “program” solely refer to a “Turing machine” or any other Turing-equivalent mathematical program for that matter? If so, then we could perceive the statement as [completely] abstract and correct; for then it would be a rephrasing of Martin Davis's 1958 account [3, p.70] of Alan Turing's 1936 paper. Or, as a second interpretation, does a “program” refer to a computer program that we can indeed “devise” and that may or may not “terminate”?</p>
<p>Based on a detailed study of Minsky's book, I assert that the right answer leans towards the second interpretation, as also the follow-up excerpt from his book indicates:</p>
<blockquote><p>(This observation holds only for <strong>programs</strong> in computers with essentially unlimited secondary storage, since otherwise the computer is a finite-state machine and then the halting problem is in fact solvable, at least in principle.) [8, p.153, my emphasis]</p>
</blockquote>
<p>Paraphrasing Minsky, if we view computer programs as Turing machines, then we have an impossibility result with severe practical implications. However, Minsky's reasoning is only valid if the following two assumptions hold (each of which is wrong):</p>
<ol><li> A computer program is a synonym for a mathematical program.</li>
<li>The mathematical program (mentioned in the previous sentence) has to be equivalent to a Turing machine program and not to, say, a primitive recursive function.</li>
</ol><p>In other words, Minsky did distinguish between finite and infinite objects, but not between abstract objects (Turing machines) and concrete physical objects (computers and storage), let alone between abstract objects and technical artefacts (computer programs).</p>
<p>The second assumption often goes unmentioned in the literature exactly because computer programs and mathematical programs are frequently conflated. Contrary to what Minsky wrote, <a href="/node/143">a computer with a finite memory is <em>not</em> a finite state machine</a>, it can only be modeled as such.</p>
<p>While I have criticized the first assumption philosophically, the second assumption can easily be scrutinized by having a good look at the history of computer science. Specifically, I will complement the findings of the historians Michael Mahoney [7, p.133] and Edgar Daylight [5, Ch.3] and support the following thesis: computer scientists mathematically modeled actual computations in diverse ways, and many of them did not resort to the Turing-machine model of computation (or to any other Turing-equivalent model). In a word, there never has been a standard model of computation throughout the history of computer science; it is the quest for such a model and not the model itself that brought many computer scientists together.</p>
<p> </p>
<p><strong>Revisiting the Gatekeeper</strong></p>
<p>That, then, was an excerpt from my rejected POPL paper. The extract conveys Minsky's 1967 stance with regard to the unsolvability of the halting problem. The question of interest here is whether Minsky intentionally fused the two categories of mathematical programs and computer programs. Perhaps he was merely crafting his sentences with brevity in mind and I am making too much of all this.</p>
<p>My scrutiny of the writings of <a href="/node/139">John Reynolds</a>, <a href="/node/140">Michael Hicks</a>, <a href="/node/141">Andrew Appel</a>, <a href="/node/142">Dave Parnas, Swarat Chaudhuri</a>, <a href="/node/143">CACM reviewers</a>, and Marvin Minsky, at least hints at the possibility that epistemic pluralism is a major feature of computer science too. It is precisely Raymond Turner and like-minded scholars who are starting to lay the philosophical foundations of our emerging field. The POPL Gatekeeper, however, has expressed a very different opinion:</p>
<blockquote><p>Most criticisms of particular authors and their published claims seem dubious. I think these authors really do understand all the relevant issues and have just crafted certain sentences with brevity in mind. It doesn't work in practice to footnote every sentence with a review of all of its philosophical foundations!</p>
</blockquote>
<p>It works to be precise at least once. Conflations abound. Or, to borrow from Timothy Colburn's analysis, here's what Tony Hoare wrote in 1986:</p>
<blockquote><p>Computer programs are mathematical expressions. They describe, with unprecedented precision and in the most minute detail, the behavior, intended or unintended, of the computer on which they are executed.</p>
</blockquote>
<p>This quote, which I have copied from page 132 in Colburn's book <a href="https://www.amazon.com/Philosophy-Computer-Science-Bureaucarcies-Administration/dp/156324991X"><em>Philosophy and Computer Science</em></a>, is reminiscent of <a href="/node/142">Chaudhuri's words which Parnas</a> and subsequently I, too, have scrutinized. Or, to use Peter Naur's 1989 words, as cited by Colburn on page 147 in his book <em>Philosophy and Computer Science</em>:</p>
<blockquote><p>It is curious to observe how the authors in this field, who in the formal aspects of their work require painstaking demonstration and proof, in the informal aspects are satisfied with subjective claims that have not the slightest support, neither in argument nor in verifiable evidence. Surely common sense will indicate that such a manner is scientifically unacceptable.</p>
</blockquote>
<p>One such subjective claim is, once again, that “full formal verification” is possible; that is,</p>
<blockquote><p>“full formal verification, the end result of which is a proof that the code will always behave as it should. Such an approach is being increasingly viewed as viable.” — citing <a href="/node/140">Michael Hicks</a></p>
</blockquote>
<p>If the POPL Gatekeeper were to “really understand all the relevant issues” raised in my rejected POPL paper him- or herself, then s/he would either agree with me or with Michael Hicks but not both. The Gatekeeper can't have both ways.</p>
<p> </p>
<p><strong>Pluralism is a Virtue</strong></p>
<p>Researching the history and philosophy of our young field already has practical value today. Grasping the <em>multitude</em> of definitions of a “computer program” leads to conceptual clarity and, specifically, to an increased understanding of seemingly conflicting views on computer science. For example the <a href="/node/142">Parnas-Chaudhuri exchange</a> is essentially a clash between definitions 1. and 3., presented at the beginning of this blog post. Each actor associates a different meaning to the term “computer program.”</p>
<p>Appreciating the plurality of “computer program” definitions can lead to better computer engineering practices. For instance, Byron Cook’s article ‘Proving Program Termination’ [2] and Daniel Kroening and Ofer Strichman’s book, <em>Decision Procedures: An Algorithmic Point of View</em> [6], together present two complementary views on what a “computer program” entails in the present century. For Cook, the variables in the following program text range over integers with infinite precision and, therefore, follow Strachey’s 1973 programming view and show some resemblance with Minsky’s account on page 153 of his 1967 book.</p>
<p>x : = input(); <br />y : = input(); <br />while x > 0 and y > 0 do <br /> if input() = 1 then x : = x - 1;<br /> else y : = y - 1; fi <br />done</p>
<p>Kroening and Strichman, by contrast, present an alternative perspective in which all program variables (in the above program text) are defined over finite-width integers and this aligns more with the view held by Dijkstra (1973) and with Minsky’s account on page 25. The implication is that the software tools built by Cook differ in fundamental ways from those developed by Kroening and Strichman. (A descent analysis of Peter Naur’s writings will reveal yet another view on programming.) Good engineers today benefit from this pluralism by using the tools provided from <em>both</em> camps. They will not object if they are requested to use different semantic models for the same C computer program — a point that <a href="/node/139">I have tried to stress before</a>. </p>
<p> </p>
<p><strong>References</strong></p>
<p>[1] Bensaude Vincent, ‘Studies in History and Philosophy of Science Part C: Studies in History and Philosophy of Biological and Biomedical Sciences,’ 44:2, 122–129, 2013.<br />[2] Cook, Podelski, Rybalchenko, ‘Proving Program Termination,’ CACM, 54:5, 88–98, 2011.<br />[3] M. Davis. <em>Computability and Unsolvability</em>. McGraw-Hill, New York, USA, 1958.<br />[4] Hoare, Allison, Incomputability, ACM Comp. Surveys 4.3, 169–178, 1972.<br />[5] D. Knuth and E. Daylight. <a href="http://www.lonelyscholar.com/knuth2"><em>Algorithmic Barriers Falling: P=NP?</em></a> Lonely Scholar, Geel, 2014.<br />[6] Kroening, Strichman, <em>Decision Procedures: An Algorithmic Point of View</em>, Springer, 2008.<br />[7] M. Mahoney. <em>Histories of Computing</em>. Harvard University Press, Cambridge, Massachusetts/London, England, 2011.<br />[8] M. Minsky. <em>Computation: Finite and Infinite Machines</em>, Prentice-Hall, 1967.</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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Tue, 11 Oct 2016 14:58:11 +0000egdaylight144 at https://dijkstrascry.comhttps://dijkstrascry.com/node/144#commentsThe POPL Gatekeeper
https://dijkstrascry.com/node/143
<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">6 October 2016</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>There is an obvious distinction to be made between computers (which include laptops and iPads) on the one hand and mathematical models on the other hand. Strictly speaking, it is wrong to say that “a computer <em><span style="text-decoration: underline;">is</span></em> a finite state machine.” That's like <em>speaking about a mathematical model as if it coincides with reality</em>. Unfortunately, it is unusual to make these kinds of observations explicit in computer science, as I am doing now and as I have done in my paper entitled `Category Mistakes in Computer Science at Large.'</p>
<p>My paper on Category Mistakes was rejected by POPL referees for some very good reasons (albeit non-technical ones). I've <a href="/node/142">introduced the POPL Gatekeeper in my previous post</a> and the objective here is to discuss the following remark made by the Gatekeeper:</p>
<blockquote><p>I'm not sure why CACM reviewers would ignore the difference between real-world systems and their mathematical models. I don't actually see that mistake in the quoted reviews.</p>
</blockquote>
<p>I received this genuine comment on October 3rd, 2016. In my rejected POPL paper, I present quoted reviews from anonymous referees of the Communications of the ACM (CACM) — reviews that I received on January 24th, 2016, after having submitted a prior version of my rejected POPL paper to the CACM in the fall of 2015. (For the sociological record: the reviews received from the CACM are much more elaborate, they convey more <em>how</em> each reviewer thinks. The CACM referees have provided pages of feedback. In retrospect, this is perhaps to be expected. The CACM is after all a journal while “POPL” refers to an annual conference which has a well-defined scope of research.)</p>
<p>As I've mentioned in my previous blog post, I don't agree with the Gatekeeper's assessment. In my words:</p>
<blockquote><p>I'm afraid reviewers of the CACM <em>have</em> applied faulty reasoning and I also believe I have illustrated <em>precisely that</em> in my POPL paper (but that's a topic I will address another day).</p>
</blockquote>
<p>I will address that topic now. I will, however, only discuss a <em>strict subset</em> of all the CACM reviews that I cover in my rejected POPL paper. I will thus only present the basics here and leave the really interesting stuff for later.</p>
<p><strong>Computers vs. Mathematical Models</strong></p>
<p>The categorical distinction between computers and mathematical models often goes unnoticed. A computer <em>is not</em> a finite state machine. The former is a <em>concrete physical</em> object and it can be <em>mathematically modeled</em> by the latter, which is an <em>abstract</em> object. Well, here then is the first comment that I have received from a referee of the CACM:</p>
<blockquote><p>My laptop is a universal Turing machine, but its tape size is of course limited by the finiteness of human resources.</p>
</blockquote>
<p>If you limit the tape size of a universal Turing machine, you may end up with, say, a linear bounded automaton or even a machine that is computationally equivalent to a finite state machine. You thus end up with another <em>mathematical</em> model of computation but <em>not</em> with a laptop (i.e., a concrete physical object). To be more precise:</p>
<blockquote><p>You <span style="text-decoration: underline;">can't</span> use <em>human</em> resources to limit the size of a <em>mathematical</em> object, i.e., the tape. Note that the “tape” indeed denotes a mathematical object and <em>not</em> a physical object, contrary to what the word “tape” seems to suggest.</p>
</blockquote>
<p>You can introduce mathematical restrictions to limit the size of a mathematical object. Likewise, you can use human resources to limit the size of a concrete physical object (such as a laptop). But, once again:</p>
<blockquote><p>A Turing machine <em>is</em> a mathematical object, it is <em>not</em> a computer. This is contrary to what the word “machine” seems to suggest.</p>
</blockquote>
<p>I know where the CACM reviewer is coming from. I, too, have been educated as a computer scientist and also used to speak about my mathematical model as if it coincides with reality. The right way to put it, once again, is as follows:</p>
<blockquote><p>Placing finite bounds on an abstract object (Turing machine) does not make it a concrete physical object (laptop). Instead, it results in another abstract object (e.g., a linear bounded automaton or a finite state machine) that can potentially serve as another mathematical model for the physical object at hand.</p>
</blockquote>
<p>I agree that these words convey a very trivial distinction. But missing the distinction can easily lead to faulty reasoning. For example, it makes no sense to say that a laptop is Turing complete. Only a mathematical model of computation can be Turing complete. Likewise, it makes no sense to question whether your iPhone is Turing complete or not. Unfortunately, these statements can be found all over the place, not only in peer reviews but also in articles and in books, published by reputable publishers. (I discuss several peer reviewed articles in my rejected POPL paper.) I've even had discussions with colleagues who start proving on the blackboard that my laptop is Turing complete. They really think they are giving a <em>mathematical</em> proof. As I emphasize in my (often rejected) writings:</p>
<blockquote><p>It is the mathematical model of a laptop that may or may not be Turing complete, not the laptop itself. Yet, many computer scientists disagree with this statement and erroneously place both objects in the same category. This is where a category mistake occurs.</p>
</blockquote>
<p>Comparing a laptop with a Turing machine is only warranted with the proviso that we all agree we are reasoning across <em>separate</em> categories.</p>
<p>Likewise, and as I have already illustrated to some extent in my previous blog posts, it makes no sense to claim, nor to attempt to mathematically prove, any of the following:</p>
<ol><li>The computer programming language C is Turing complete.</li>
<li>The Halting Problem of computer programs residing in my laptop (or any laptop for that matter) is unsolvable.</li>
</ol><p>I understand that many programming language experts view a “programming language” as a mathematical object. That's why I want to explicitly distinguish between a “computer programming language” and a “mathematical programming language.” I take C to be a computer programming language and I know that many computer scientists (= typically non programming language experts) who defend claim 1. do so too and, therefore, make a category mistake. In fact, they often simply do not distinguish between the computer programming language and their mathematical model. That is the main point I am repeatedly trying to make.</p>
<p><strong>Abusing the Halting Problem</strong></p>
<p>Grasping the significance of the observations made so far is not easy for here is yet another response that I have received from a referee of the CACM and which I have also reported in my rejected POPL paper:</p>
<blockquote><p>What does the undecidability proof of the halting problem for computer programs actually tell us. Like diagonalization proofs in general it may be viewed finitely as saying that, if there is a bound M on the size of accessible computer memory, or on the size of computer programs, or any other resource, then no computer program subject to the same resource bounds can solve the problem for all such computer programs.</p>
</blockquote>
<p>The previous remark and the follow-up remark, presented below, are only correct if we accept the following two assumptions (each of which is wrong):</p>
<ol><li>A computer program is a synonym for a mathematical program. </li>
<li>The mathematical program (mentioned in the previous sentence) has to be equivalent to a Turing machine program and not to, say, a primitive recursive function. </li>
</ol><p>The reason why the second assumption has to hold is merely because the referee is referring to the halting problem of Turing machines. Continuing:</p>
<blockquote><p>If computer program A solves correctly all halting problems for computer programs respecting bound M, then the counterexample computer program T must exceed that bound, which is why A fails for T. To solve problems of computer programs, one needs an ideal program.</p>
</blockquote>
<p>The quote hints at a distinction that has to be made between finite and infinite objects (with the latter being labeled “ideal”) but the categorical distinction between computer programs and mathematical programs goes unnoticed. Again, this is where a category mistake occurs. The undecidability proof of the halting problem is about <em>mathematical</em> programs only, and not about <em>computer</em> programs. The diagonal argument can only be applied to mathematical objects. So, to be frank, the referee thinks s/he is giving a mathematical argument but, in fact, s/he is demonstrating faulty reasoning. S/he is <em>not</em> proving something about <em>computer</em> programs but about a *particular* mathematical model of a computer program! So much for mathematical rigor.</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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Thu, 06 Oct 2016 09:51:50 +0000egdaylight143 at https://dijkstrascry.comhttps://dijkstrascry.com/node/143#commentsParnas and Chaudhuri
https://dijkstrascry.com/node/142
<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">4 October 2016</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>The topic of `Category Mistakes,' which I have discussed in my four previous blog posts is not limited to digital systems. Engineers in all areas use models and they, too, can potentially fall into the trap of mistaking the model for reality.</p>
<p>Dave Parnas told me in August 2016 that one of his favorite examples in this regard is `Ohm's Law,' which states that V = I*R. In reality, the ratio between current (I) and voltage (V) varies, i.e., the relationship is not actually linear. Engineers can use this law to analyze a circuit and verify that it has the desired behavior only to find that the circuit fails in certain conditions. Parnas gives the following example:</p>
<blockquote><p>The circuit may overheat and the resistance (R) will change. Ohm’s Law can be made an accurate description of the device by adding conditions, e.g. V-I*R < Delta if a < I < b etc. The result will be much more complex but it will give conditions under which the model’s conditions are accurate. Even this is a lie as it makes assumptions about ambient temperature and the aging of the components that are not stated.</p>
</blockquote>
<p>Parnas's main point is that engineers must be aware of the limitations of models as descriptions. More on Parnas's views can be found in <a href="http://www.lonelyscholar.com/node/17">the first panel discussion</a> held at ETH Zurich in November 2010. Parnas concludes by noting that this awareness is completely missing in the UML (Unified Modeling Language) and MDE (Model-Driven Engineering) literature. Can the same be said about the programming language literature?</p>
<p>Category Mistakes are also typically found in physics. A colleague in computer science recently explained to me that several publications contain statements of the following kind:</p>
<blockquote><p>Goedel proved that time travel is possible.</p>
</blockquote>
<p>What Goedel did prove is that time travel is in principle possible according to his mathematical model (i.e., with his chosen equations). Of course, one could argue that physicists frequently choose to craft their sentences with brevity in mind and that they <em>are</em> well aware of the fact that they are modeling in the first place. This is precisely the kind of response I received from a POPL referee with regard to my rejected paper, entitled: `Category Mistakes in Computer Science at Large.' When I give this kind of response to my colleague in connection with the previous statement about Goedel, he insists that some physicists really do believe that Goedel proved that time travel is possible. As I have argued in my previous blog posts, I believe the same can be said about computer scientists.</p>
<p>Similar remarks can be made about several other disciplines, including linguistics and mathematics. Concerning the latter, here is what <a href="http://pauli.uni-muenster.de/~munsteg/arnold.html">V.I. Arnold said in 1997</a>:</p>
<blockquote><p>The mathematical technique of modeling consists of [...] <em>speaking about your deductive model in such a way as if it coincided with reality</em>. The fact that this path, which is obviously incorrect from the point of view of natural science, often leads to useful results in physics is called “the inconceivable effectiveness of mathematics in natural sciences” (or “the Wigner principle”). [my emphasis]</p>
</blockquote>
<p>Likewise, researchers in computer science actually believe the following statement:</p>
<blockquote><p>“full formal verification, the end result of which is a proof that the code will always behave as it should. Such an approach is being increasingly viewed as viable.” — <a href="/node/140">citing Michael Hicks</a></p>
</blockquote>
<p>So Hicks says we can have a mathematical proof about the behavior of an engineered system. Not so. The best we can do is prove mathematical properties about <em>some</em> mathematical model of <em>the</em> running system. And doing so can, indeed, have great practical value. Moreover, I advocate — and I also believe this is happening (and always has been happening) in engineering — using <em>multiple</em> (and complementary) semantic models for the <em>same</em> digital technology; that is, for the same C computer program. Doing that will allow us, engineers, to have some more confidence that the code behaves “as it should.”</p>
<p> </p>
<p><strong>1. The POPL Gatekeeper</strong></p>
<p>It did not come as a surprise to me when I received an email on October 3rd, 2016, explaining that my POPL paper `Category Mistakes in Computer Science at Large' was officially rejected. Nor do I in any way wish to ridicule the peer review process, which I consider to be professional and honest. I firmly believe the reviewer did a very good job in:</p>
<ol><li>Justifiably preventing my unorthodox analysis from entering the POPL'17 proceedings. </li>
<li>Protecting <em>me</em> from making a fool of myself in an auditorium full of programming language experts.</li>
</ol><p>That said, I still think that the POPL referee did not fully comprehend my analysis (which, again, does not mean that s/he should have accepted my paper for publication). It should also be remarked that there was a second reviewer who rejected my paper too. His or her comments were very brief and I shall therefore postpone discussing them. I will disseminate my rejected POPL paper along with the two reviews in the near future. Why not? Seeking a dialogue between different groups of scholars can lead to <em>conceptual clarity</em>. Here's a time line of events:</p>
<ol><li>In the first week of July 2016, I submitted my POPL paper (to be disseminated later).</li>
<li>On September 14th, 2016, I received two peer reviews (to be disseminated later).</li>
<li>On the same day I wrote and submitted a short rebuttal (presented below).</li>
<li>On October 3rd, 2016, I received the official rejection of my POPL paper, along with a reply (presented below) from the first reviewer pertaining to my rebuttal. </li>
</ol><p> </p>
<p><strong>My Rebuttal (September 14th, 2016)</strong></p>
<blockquote><p>The reviews are very good and informative.</p>
<p>I am willing to believe the first reviewer when he says that my findings are already well understood in the POPL community. It should be remarked though that the CACM community, by contrast, fundamentally disagrees with my "category mistakes" and thus also with the reviewer's views. What to do about this?</p>
<p>Moreover, multiple POPL members still tell me that it *is* possible to fully verify a digital *system*, even after having studied my work in detail. So the reviewer's claim about the POPL community does not mix well with my daily experience. Please tell me what I can do about this? Should I abandon this research topic?</p>
<p>I do take gentle issue with the way the first reviewer frames my works: I am not presenting "anecdotes" nor am I just citing a few papers. Clearly my reference to Parnas and Chaudhuri backs up *my* story, not the reviewer's.<strong><br /></strong></p>
</blockquote>
<p> </p>
<p><strong>Reply by Reviewer #1 (October 3rd, 2016)</strong></p>
<blockquote><p>I'm not sure why CACM reviewers would ignore the difference between real-world systems and their mathematical models. I don't actually see that mistake in the quoted reviews. The standard convention is that a reference to a programming language refers to the abstract mathematical object, which is unproblematic, since today it is routine to define full-fledged languages unambiguously.</p>
<p>I don't think the Parnas-Chaudhuri exchange is problematic, because Parnas is not a member of the POPL community and likely ran into similar problems interpreting papers from it.</p>
</blockquote>
<p> </p>
<p><strong>My analysis (October 4th, 2016)</strong></p>
<p>Four quick points:</p>
<p>1. The reviewer is quite right in stressing that “today it is routine to define full-fledged languages unambiguously” and perhaps I miss-portrayed (albeit in just one or two sentences) the accomplishments of the POPL community in my rejected paper.</p>
<p>2. I'm afraid reviewers of the CACM <em>have</em> applied faulty reasoning and I also believe I have illustrated <em>precisely that</em> in my POPL paper (but that's a topic I will address another day).</p>
<p>3. Reference to a programming language as an abstract mathematical object is only “unproblematic” if we keep in mind that it is <span style="text-decoration: underline;"><em>a</em></span> mathematical model of <em>the</em> technology under scrutiny. That's why I explicitly distinguish between a mathematical programming language and a computer programming language. They are categorically distinct. Furthermore, assuming by convention that there is a 1-to-1 relation between a computer program and a mathematical program is fine. But using that premise to project results from, say, computability theory onto engineering is often wrong and misleading. (See my previous four posts for more information, starting with the first one: <a href="/CategoryMistakes">here</a>. I think <a href="/node/140">my post about Michael Hicks</a> makes this point clearly.)</p>
<p>4. The reviewer sidesteps my claim that “multiple POPL members still tell me that it *is* possible to fully verify a digital *system*, even after having studied my work in detail.” I am willing to bet that the reviewer has no clue what I am talking about; i.e., that s\he has not understood my paper very well after all. Of course, that is first and foremost <em>my</em> mistake. I am, after all, still struggling to find the right words and tone to get my message across to the POPL community.<strong> </strong></p>
<p>But what I want to discuss here and now is the implicit statement that Dave Parnas and I are “non members of the POPL community” (which is OK) and <strong>therefore</strong><em> <span style="text-decoration: underline;">we</span> have misinterpreted</em> — and continue to misinterpret — the work of Chaudhuri and other POPL members (which is not OK). Talking about the elite of computer science! From a sociological angle, that's a rather impressive remark. It fits right in the 2004 book <a href="https://mitpress.mit.edu/books/mechanizing-proof"><em>Mechanizing Proof: Computing, Risk, and Trust</em></a>, written by the sociologist Donald MacKenzie. Instead, the POPL community could welcome the scrutiny of Parnas and like-minded engineers in order to prevent two big communities (software engineering and computer science) from drifting further apart.</p>
<p>In retrospect, surely Chaudhuri et al. grasp the difference between a computer program and a mathematical program. (After all, who would not be able to make such a simple distinction?) Moreover, based on the extensive feedback from the first reviewer (not shown in the present blog post), I am inclined to re-phrase several sentences of my rejected POPL paper. I will only do so in future writings and intentionally present my original and imperfect narrative in the sequel.</p>
<p>That all being said, and as you can judge for yourself below, it is Dave Parnas who seeks conceptual clarity and who <em>does understand</em> what the POPL community is doing. Parnas is asking Chaudhuri et al. to be more precise in the way they formulate their research findings and not to oversell their mathematical results. It is Parnas who wants to differentiate between the “computer program” and its mathematical model(s) while Chaudhuri et al. apparently do not want to abide with him. </p>
<p>As promised, now follows the introduction of my unorthodox and rejected POPL paper.<strong> </strong></p>
<p> </p>
<p><strong>2. The Introduction of my Rejected POPL Paper</strong></p>
<p>In his 1985 paper `The limits of correctness' [39], Brian Cantwell Smith discussed an important issue concerning program verification. He pointed out that a program always deals with the world through a model, it cannot deal with the world directly. There always is a layer of interpretation in place. Therefore, if we define a correct program as a program that does what we intended it to do, as opposed to what we formally specified it to do, proving a program correct is intrinsically very difficult. (The word “we” refers to my former student, Rosa Sterkenburg, and myself. Rosa is a co-author of the present introduction but carries no responsibility for the rest of this article.)</p>
<p>To illustrate the difficulty underlying Smith's <em>world-model</em> relation, assume we have a mathematical model of the world in which all apples are modeled as green and all strawberries as red. With this model it is quite simple to distinguish an apple from a strawberry, simply use the color to differentiate between the two kinds of fruit. If we thus write a program that can discriminate between red and green, then, at least with respect to our model, we can mathematically prove that our program can indeed distinguish between apples and strawberries. However, in the real world there exist red apples as well. So our model is not perfect; our proven correct program will tell us a red apple is a strawberry. As Smith put it:</p>
<blockquote><p>Just because a program is ‘proven correct’, you cannot be sure that it will do what you intend. [39, p.18]</p>
</blockquote>
<p>Smith argued that it is necessary for our model of the world, or <em>any</em> mathematical model for that matter, to be incorrect in some ways. For, if a model were to capture everything, it would be too complex to work with [39, p.20-21]. In the apple and strawberry example, the model need not capture the molecular structure of the fruits; doing so would presumably over-complicate matters for the application at hand. We need models to abstract away irrelevant — and, unfortunately, also relevant — aspects of the world in order to make an industrial problem mathematically tractable.</p>
<p>More important for the present article is the similar, yet slightly different, <em>programming-model</em> relation; that is, the relation between a programming language and the computer programs written in that language on the one hand and their mathematical counterparts on the other hand. This is a relation that Smith did not address in his paper. When proving a property about a computer program, such as deadlock prevention, some mathematical model of that program is used instead of the program itself. As a result, our formal proof about the program tells us something about it's model, and only indirectly something about the program. Here, too, we have the problem that our model is not perfect for it relies on one or more key abstractions from what is specified in the programming language's manual. Depending on what is written in that manual and how we choose to model the language at hand, two possible — and very different — key abstractions could be:</p>
<ul><li>abstraction A_{I}^{pos}, which allows for the representation of <em>arbitrary large positive integers</em>, and</li>
<li>abstraction A_{R}, which allows for the representation of <em>infinite precision real numbers</em>.</li>
</ul><p>(I could equally well consider some related issues — such as (1) an unbounded number of memory locations that can be addressed, and (2) an unbounded length of programs that can be compiled — but choose not to do so here.)</p>
<p>Moreover, the language manual, as David Harel puts it nicely in his book <em>The Science of Computing</em>, contains “a wealth of information concerning both syntax and semantics, but the semantical information is usually not sufficient for the user to figure out exactly what will happen in each and every syntactically legal program” [23, p.52-53]. Defining a formal syntax of a programming language is not considered a major problem anymore since the advent of the Backus-Naur Form (BNF) notation, but finding adequate formal semantics has remained a vexing research topic from the early 1960s up till this day.</p>
<p>In the present exposition a “mathematical model” of a program (or programming language) refers to both the formal syntax and a formal semantics of the program (or programming language) at hand, although the formal syntax will often go unmentioned. It should be noted that in model theory, by contrast, numerals and other expressions (cf. syntax) are <em>modeled by</em> the natural numbers and other mathematical objects (cf. semantics).</p>
<p>To recapitulate, a mathematical model of a computer program is imperfect in one or more ways for its semantics relies on one or more key abstractions. As a result, and this is an important point for the rest of the paper, <em>showing that something cannot be done according to a model does not necessarily imply that it cannot be done in practice</em>. Of course, one's formal semantics may become the standard definition of the programming language under study, but that does not invalidate the italicized statement made in the previous sentence.</p>
<p><strong>The Chaudhuri-Parnas Dialogue</strong></p>
<p>To already illustrate some of the issues just raised, we briefly turn to two recent writings of Swarat Chaudhuri [5,6]. Chaudhuri has studied properties of programs that are necessary conditions for a correct program to possess in his mathematical framework. Starting with his 2012 article `Continuity and Robustness of Programs' [5], Chaudhuri and his co-authors, Gulwani and Lublinerman, discuss a way to prove mathematical continuity of programs. A continuous program is not per se correct, but a correct program needs to be robust, and therefore, according to the authors it needs to be continuous.</p>
<p>Chaudhuri, Gulwani, and Lublinerman do not address the world-model relation nor the programming-model relation in their 2012 article. While the first relation does not seem very relevant to us either with regard to their article, the second relation is, we believe, significant. To put it candidly, Chaudhuri et al. do not seem to be aware that they are not proving something about their programs, but that they are proving something about some model of their programs. This is very clearly pointed out by David Parnas in a reaction to their article. Parnas says:</p>
<blockquote><p>Rather than verify properties of an actual program, it examined models of programs. Models often have properties real mechanisms do not have, and it is possible to verify the correctness of a model of a program even if the actual program will fail. [36]</p>
</blockquote>
<p>Parnas specifically describes what he thinks is problematic about the mathematical assumptions underlying Chaudhuri et al.'s model:</p>
<blockquote><p>The article ignored the problem by both declaring: ‘...our reals are infinite-precision’ and not specifying upper and lower bounds for integers. [36]</p>
</blockquote>
<p>Because of these abstractions, which include what we have called abstractions A_{R} and A_{I}^{pos}, Parnas concludes in a similar way to what Smith wrote in 1985. Proving something correct does not mean it will do what you want. “Some programs,” Parnas continues,</p>
<blockquote><p>can be shown to be continuous by Chaudhuri’s method but will exhibit discontinuous behavior when executed. [36]</p>
</blockquote>
<p>Chaudhuri et al. reply to this critique as follows:</p>
<blockquote><p>From a purely mathematical perspective, any function between discrete spaces is continuous, so all <em>computer</em> programs are continuous. [36, my emphasis]</p>
</blockquote>
<p>This reaction suggests that Chaudhuri et al. are not aware that considering a computer program as a mathematical function is a modeling step. A computer program is — and this will become our main conceptual point — categorically different from a mathematical program, even if the latter relies solely on finite abstractions. That is, a C program residing in a laptop (i.e., a computer program) is categorically distinct from its mathematical model, even if the semantics is a “real semantics,” i.e., a “detailed and cumbersome low-level model” of C. (The words just cited come from Harvey Tuch et al. [43] and we shall see in Section 5 whether Tuch et al. agree with our categorical distinction or whether they reason like Chaudhuri et al.)</p>
<p>In a later paper entitled `Consistency Analysis of Decision-Making Programs' [6], Chaudhuri, Farzan, and Kincaid do, however, address some of the issues raised by Smith in 1985. They write:</p>
<blockquote><p>Applications in many areas of computing make discrete decisions under uncertainty, for reasons such as limited numerical precision in calculations and errors in sensor-derived inputs. [6, p.555] </p>
<p>Since the understanding of nontrivial worlds is often partial, we do not expect our axioms to be complete in a mathematical sense. [6, p.557]</p>
</blockquote>
<p>These words are related to the model-world relation, which was not addressed in Chaudhuri's paper about continuity. With this remark Chaudhuri acknowledges that mathematical modeling of the real world is needed to get things done on a computer. Chaudhuri also indicates that this understanding usually is not perfect, which is close to Smith’s point that one can never aspire having a perfect mathematical model. That said, Chaudhuri does not address the stringent programming-model relation and, hence, does not respond to Parnas's criticism.</p>
<p>Smith, Parnas, and some other software scholars consistently and sometimes explicitly distinguish between <em>concrete physical objects</em> such as a laptop, <em>technical artefacts</em> such as the programming language C, and <em>mathematical models</em> such as a finite state machine and a universal Turing machine. According to them, both a laptop and a finite state machine are finite objects, but the former is physical while the latter is mathematical. Likewise, equating a laptop with a universal Turing machine is problematic, not primarily because the former is finite and the latter is infinite, but because the former moves when you push it and smells when you burn it while the latter can neither be displaced nor destroyed.</p>
<p> </p>
<p><strong>References</strong></p>
<p>[5] S. Chaudhuri, S. Gulwani, and R. Lublinerman. Continuity & robustness of programs. Communications of the ACM, 55(8):107–115, 2012. </p>
<p>[6] S. Chaudhuri, A. Farzan, and Z. Kincaid. Consistency analysis of decision-making programs. In Proceedings of the 41st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 555–567, 2014.</p>
<p>[23] D. Harel. <em>The Science of Computing: Exploring the Nature and Power of Algorithms</em>. Addison-Wesley, 1987, 1989.</p>
<p>[36] D. Parnas. On Proving Continuity of Programs. Letter to the Editor of the Communications of the ACM, 55(11):9, November 2012.</p>
<p>[39] B. Smith. The limits of correctness. ACM SIGCAS Computers and Society, 14,15:18–26, January 1985.</p>
<p>[43] H. Tuch, G. Klein, and M. Norrish. Types, Bytes, and Separation Logic. In Principles of Programming Languages, 2007.<strong><br /></strong></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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Tue, 04 Oct 2016 11:33:19 +0000egdaylight142 at https://dijkstrascry.comhttps://dijkstrascry.com/node/142#commentsDeep Specification and Andrew Appel
https://dijkstrascry.com/node/141
<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">25 September 2016</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>I'm reading about “the science of deep specification.” This grand research project is led by Andrew Appel and some other big names on the east coast of the USA. It is only after having read <a href="http://deepspec.org/research/">Appel et al.'s on-line research overview</a> again today that I am now 100% convinced that the vast majority of researchers in program verification have not taken the simple objections made by <a href="http://dl.acm.org/citation.cfm?id=48530">James Fetzer</a> (1988) and <a href="https://mitpress.mit.edu/books/mechanizing-proof">Donald MacKenzie</a> (2004) seriously. Again, perhaps they have some very good reasons not to have done so and then I'd like to know why. (By the way, MacKenzie's book also covers some beautiful accomplishments of Andrew Appel's father.)</p>
<p>Andrew Appel and other computer scientists often refer to a <em>computer</em> program while they are actually referring to another representation of <span style="text-decoration: underline;"><em>a</em></span> mathematical model of <em>the</em> computer program at hand. I use the term “<em>mathematical</em> program” as a synonym for “mathematical model of a computer program.” So while a computer program can represent a mathematical program, so can</p>
<ul><li>a text-on-paper representation (called a <em>paper</em> program) and</li>
<li>a text-on-screen representation (called a <em>screen</em> program) </li>
</ul><p>represent the same mathematical program.</p>
<p>For example, the following is projected onto your screen and therefore it is a screen program:</p>
<pre><code><span class="p">(</span><span class="nf">defun</span> <span class="nv">factorial</span> <span class="p">(</span><span class="nf">n</span><span class="p">)</span>
<span class="p">(</span><span class="k">if </span><span class="p">(</span><span class="nb">= </span><span class="nv">n</span> <span class="mi">0</span><span class="p">)</span>
<span class="mi">1</span>
<span class="p">(</span><span class="nb">* </span><span class="nv">n</span> <span class="p">(</span><span class="nf">factorial</span> <span class="p">(</span><span class="nb">- </span><span class="nv">n</span> <span class="mi">1</span><span class="p">)))</span> <span class="p">)</span> <span class="p">)</span></code></pre><p>Again, this textual representation, projected onto your screen, is a representation of a mathematical object, i.e., a mathematical program. (One can perhaps also say that it is a textual representation of a computer program. I definitely take no issue with that viewpoint. But, in order to avoid confusion, I will not use the verb "to represent" in that manner.) One might be tempted to say that the textual representation <em>is</em> a computer program. This is frequently not a problem but it is in the current setting where formal methodists, themselves, want us to be merciless precise. So let's indeed try to be crystal clear.</p>
<p>The paper program, the screen program, and the computer program are three different representations of the mathematical model. (They are three different <a href="/node/139">technical artefacts</a>.) The first and second representation, intended for humans to read, are very different from the third. A computer program resides electronically in a specific computer and is (a) what we all would like to get “correct” and (b) what we all have difficulty comprehending because it is an artefact engineered for a digital machine.</p>
<p>Coming now to Appel et al.'s research overview. The authors state that</p>
<blockquote><p>Until recently "program verification logics have not been `live:' they have been about models of the program."</p>
</blockquote>
<p>But any <em>mathematical</em> endeavor such as program verification can at best be about mathematical models of the engineered system at hand. That system, in turn, can contain one or more computer programs. Each computer program can be modeled in one or more ways by a mathematically-inclined researcher. Likewise, one can mathematically model a <em>running</em> computer program by resorting to, say, an operational semantics of the computer program under scrutiny. But how can mathematics become `live'? What, exactly, is this supposed to mean?</p>
<p>Continuing with Appel et al.'s words:</p>
<blockquote><p>Program verification logics are now “connected directly and mechanically to the program”.</p>
</blockquote>
<p>Notice that Appel et al. oftentimes use the word “program” (such as the last word in the previous sentence) as an abbreviation for “computer program” — i.e., the real mechanical stuff. But the first occurrence of the word “Program” in the previous quote has to refer to a mathematical program! For, how could you prove a logical statement without having a semantic model of the engineered computer program? Or, to be more precise, the first occurrence of “Program” has to refer to a textual representation of Appel et al.'s chosen mathematical program while the last occurrence has to refer to an electronic — humanly unreadable — representation, i.e., a computer program.</p>
<p>In other words, the authors conflate their textual representation of their mathematical program and an electronic representation of that same mathematical program (i.e., the computer program that we all want to get “correct”).</p>
<p>Appel et al. are basically saying what <a href="/node/139">John Reynolds</a> and <a href="/node/140">Michael Hicks</a> have said before, namely that full verification of a hw/sw system is possible, both in principle and in practice. My claim is that this is not possible in principle but that program verification nevertheless does have a lot to offer in practice, especially if formal methodists will get their terminology right when disseminating their research findings to, say, software engineers in industry.</p>
<p>Continuing with the words of Appel et al.:</p>
<blockquote><p>“we envision this network of verified software components, connected by deep specifications—specifications that are <em>rich, live, formal,</em> and <em>two-sided</em>.”</p>
</blockquote>
<p>Some of these italicized words I do not understand at all but perhaps it's just me. Continuing:</p>
<blockquote><p>“whatever properties are proved about a program will actually hold when the program runs”</p>
</blockquote>
<p>This latter sentence exemplifies a category mistake, essentially already pointed out by <a href="http://dl.acm.org/citation.cfm?id=48530">Fetzer in 1988</a> and refined by me as follows: One can mathematically prove a <em>mathematical property</em> on a mathematical model of a computer program. One cannot prove a mathematical property on a computer program, regardless of whether the latter is running or not. So the first occurrence of “program” in the previous quote refers to a mathematical program while the latter occurrence — “the program runs” — has to refer to a computer program.</p>
<p>To conclude, Appel and his fellow researchers fuse the category of mathematical objects (which includes mathematical programs) with the category of engineered systems (which includes computer programs). Perhaps there are very good reasons to do so and I am merely demonstrating my ignorance. In any case, the `science of deep specification' remains intriguing to me because I am not even able to grasp some of its basic principles.</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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Sun, 25 Sep 2016 13:12:34 +0000egdaylight141 at https://dijkstrascry.comhttps://dijkstrascry.com/node/141#commentsAnalysis Tools and Michael Hicks
https://dijkstrascry.com/node/140
<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">21 September 2016</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>Before really discussing <a href="/node/138">category mistakes</a> in computer science in follow-up posts, I will first continue testing my <a href="/node/139">aforementioned categories</a> on the writings of people I admire the most. I shall take a 2014 blog post, written by <a href="http://www.pl-enthusiast.net/2014/07/01/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it/">Michael Hicks</a> in connection with the Heartbleed bug. (His post was written on July 1st, 2014 and I accessed it on September 19th, 2016.)</p>
<p>To recapitulate, and based largely on the work of <a href="http://cswww.essex.ac.uk/staff/turnr/">Raymond Turner</a>, I distinguish between three separate categories:</p>
<ul><li>computers are <em>concrete physical objects</em>, </li>
<li>computer programs and also computer programming languages are <em>technical artefacts</em>, and </li>
<li>Turing machines, finite state machines, and prime numbers are <em>abstract objects</em>. </li>
</ul><p>Furthermore, based on the writings of James Moore, James Fetzer, Timothy Colburn, Donald MacKenzie (and others whom I have cited repeatedly in previous blog posts), at the very least, a conceptual distinction is in order between a "mathematical program" and a "computer program". Based on Turner's work, I can say today that the former belongs to the category of abstract objects while the latter belongs to the category of technical artefacts.</p>
<p>Now, coming to the blog post of Michael Hicks, I have two observations to make. First, he writes about:</p>
<blockquote><p>"full formal verification, the end result of which is a proof that the code will always behave as it should. Such an approach is being increasingly viewed as viable."</p>
</blockquote>
<p>So Hicks says we can have a mathematical proof about the behavior of an engineered system. Fetzer already made clear that this is not possible. The best we can do is prove a mathematical property about some mathematical model of a running system. And doing so can, indeed, be of great value in practice, as I experience daily. Hicks can only be right (and Fetzer is then wrong) if the mathematical object at hand and the engineered system under scrutiny belong to the same category.</p>
<p>Have I taken Hicks's words out of context? Am I wrong in linking Hicks's statement to that of <a href="/node/139">John Reynolds</a> and <a href="/node/138">Dr. X</a>? Judge for yourself. Links to statements made by Tony Hoare and other great minds in computer science have already been provided by Fetzer, Colburn, and <a href="https://mitpress.mit.edu/books/mechanizing-proof">MacKenzie</a>.</p>
<p>Regardless of whether you think Fetzer and I are wrong, at least we can all agree on the following historiographical observation: the best of the best in computer science have largely ignored the writings of philosophers of computer science. They do not mention Fetzer and the like. Perhaps they have some very good reasons not to do so (and perhaps they do not).</p>
<p> </p>
<p><strong>Soundness & Completeness</strong></p>
<p>My second point concerning Hicks's blog post is about the alleged practical implications of Rice's Theorem. This is where my own thoughts are put center stage, for the writings of Fetzer and the other aforementioned philosophers do not cover computability theory.</p>
<p>Hicks provides definitions of a "sound analysis" and a "complete analysis" — definitions that I will scrutinize later. Hicks then provides the following statement which I honestly have difficulty comprehending:</p>
<blockquote><p>Ideally, we would have an analysis that is both sound and complete [Yes], so that it reports all true bugs, and nothing else [No!].</p>
</blockquote>
<p>Even if we would have a <em>mathematical</em> analysis that is both sound and complete, then this mathematical accomplishment cannot <em>guarantee </em>something about the real world, including the behavior of the engineered <em>system</em> under scrutiny — unless, again, the mathematical object and the engineered system belong to the same category (and, <em>moreover, </em>we can specify absolutely everything about the engineered system in a concise and useful manner).</p>
<p>Is Hicks's reasoning flawed or am I missing something? This is a genuine question. In my words, a sound and complete analysis can provide engineers <em> extra confidence</em> that their system will behave appropriately in the real world.</p>
<p>Let me just mention at this point that Edsger Dijkstra, Aad van Wijngaarden, and several others would have mathematically modeled a computer program with a Turing-incomplete model of computation and, specifically, with a finite state machine. So I <em>also</em> struggle with Hick's suggestion to only use Turing-complete languages when mathematically modeling computer programming languages. I believe he makes that suggestion in the following passage:</p>
<blockquote><p>Unfortunately, such an [ideal] analysis [which is both sound and complete] is impossible for most properties of interest, such as whether a buffer is overrun (the root issue of Heartbleed). This impossibility is a consequence of Rice's theorem, which states that proving nontrivial properties of programs in Turing-complete languages is undecidable. So we will always be stuck dealing with either unsoundness or incompleteness.</p></blockquote>
<p>I definitely agree with Hicks that <span style="text-decoration: underline;"><em>if</em></span> we use Turing-complete languages, <span style="text-decoration: underline;"><em>then</em></span> we cannot ignore Rice's Theorem, "which states that proving nontrivial properties" of our <em>mathematical</em> programs (expressed in our Turing-complete language) "is undecidable." But most engineers I know don't have a preference for</p>
<ul><li>sticking to one modeling language only, nor do they </li>
</ul><ul><li>advocate a Turing-complete language <em>per se</em>. </li>
</ul><p>Contrary to programming language specialists, engineers don't want to attach <span><em>precisely one meaning</em> to each computer program and, likewise, to each computer programming language. A technical artefact can be mathematically modeled in more than one way. Each model has its pros and cons. I can model a computer with both a finite state machine <em>and</em> a linear bounded automaton. Likewise, I can model my C computer program in multiple, complementary ways; e.g., with a finite state machine, with primitive recursive functions, and with general recursive functions. </span><span>The richness lies in the multitude of ways to mathematically model reality. <br /></span></p>
<p>Do these relatively simple <em>philosophical</em> principles of programming languages have any bearing on Michael Hicks and his community of researchers?</p>
<p> </p>
<p><strong>Hicks's definitions</strong></p>
<p>The root of the confusion, I believe, lies in Hicks's defintions. Here is what Hicks says about a "sound analysis:"<strong><br /></strong></p>
<ul><li>A <em>sound</em> analysis is one that, if there exists an execution that manifests a bug at run-time, then the analysis will report the bug. </li>
</ul><p>I would like to emphasize that Hicks's "execution" is a mathematical object and, moreover, it is a mathematical object in Hicks's chosen model of computation. (Somebody else can choose <em>another</em> model of computation). Of course the word "execution" refers to a "real execution" but the reference is only indirect and the indirection can be made more explicit for the sake of conceptual clarity by distinguishing between "mathematical executions" and "real executions". The former belongs to the category of abstract objects while the latter belongs to the category of concrete physical objects.</p>
<p>Again, a sound analysis says something about the mathematical program and only <em>indirectly</em> something about the computer program under scrutiny. Furthermore, since someone else can choose another mathematical program to model the same computer program, it is misleading to suggest that there is a one-to-one mapping between the computer program and the chosen mathematical program.</p>
<p>Similar remarks can be made about Hicks's definition of a "complete analysis:"</p>
<blockquote><p>On the flip side, a <em>complete</em> analysis is one that, if it reports a bug, then that bug will surely manifest at run-time.</p>
</blockquote>
<p>There is a categorical distinction to be made between a mathematically modeled bug and a bug encountered during the execution of a real-world program. They are not the same thing.</p>
<p>Am I right to conclude that Hicks and other programming language specialists oftentimes think they are <em>directly</em> referring to <em>both</em> their mathematical model <em>and</em> the actual computer program?</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="/category-mistakes" typeof="skos:Concept" property="rdfs:label skos:prefLabel" datatype="">Category Mistakes</a></li></ul></section>Wed, 21 Sep 2016 10:56:11 +0000egdaylight140 at https://dijkstrascry.comhttps://dijkstrascry.com/node/140#comments