Edsger W. Dijkstra: Difference between revisions

Jump to navigation Jump to search
161 bytes added ,  06:15, 10 March 2021
no edit summary
m (Use also on Wikipedia template)
No edit summary
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Biography also on Wikipedia|Dijkstra|Edsger W. Dijkstra}}
{{Also on Wikipedia|Dijkstra|Edsger W. Dijkstra}}


'''Edsger Wybe Dijkstra''' was a pioneering computer scientist particularly interested in using mathematical proof to produce correct programs. In programming language design he is noted for early advocacy against the GOTO statement (like APL's [[branch]]) in his 1968 paper "A Case against the GO TO Statement", later retitled "Go To Statement Considered Harmful"<ref>Dijkstra, E.W. [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html EWD 215: A Case against the GO TO Statement]</ref>. He is known in array programming for his consistent complaints against the APL language and community.
'''Edsger Wybe Dijkstra''' was a pioneering computer scientist particularly interested in using mathematical proof to produce correct programs. In programming language design he is noted for early advocacy against the GOTO statement (like APL's [[branch]]) in his 1968 paper "A Case against the GO TO Statement", later retitled "Go To Statement Considered Harmful"<ref>Dijkstra, E.W. [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html EWD 215: A Case against the GO TO Statement]</ref>. He is known in array programming for his consistent complaints against the APL language and community.
Line 7: Line 7:
There is no evidence that Dijkstra was ever a user of APL, and several of his remarks suggest he would refuse any opportunity to use or learn it. His familiarity with the language comes from attending presentations by [[Ken Iverson]] and others, and friendship with [[Alan Perlis]], a fan of the language.
There is no evidence that Dijkstra was ever a user of APL, and several of his remarks suggest he would refuse any opportunity to use or learn it. His familiarity with the language comes from attending presentations by [[Ken Iverson]] and others, and friendship with [[Alan Perlis]], a fan of the language.


Dijkstra attended a 1963 lecture on [[Iverson notation]] by [[Ken Iverson]], and even asked a question of Iverson:<ref>Iverson, K.E. ''Formalism in Programming Languages'' ([https://www.jsoftware.com/papers/FPL.htm transcript])</ref>
Dijkstra attended a 1963 lecture on [[Iverson notation]] by [[Ken Iverson]], and even asked a question of Iverson:<ref>[[Ken Iverson|Iverson, K.E.]] ''Formalism in Programming Languages'' ([https://www.jsoftware.com/papers/FPL.htm transcript])</ref>


{{quote|Dijkstra: How would you represent a more complex operation, for example, the sum of all elements of a matrix M which are equal to the sum of the corresponding row and column indices?<br/>
{{quote|Dijkstra: How would you represent a more complex operation, for example, the sum of all elements of a matrix M which are equal to the sum of the corresponding row and column indices?<br/>
Line 35: Line 35:
* A typical characteristic of the APL devotee is, for instance, his closeness to an implementation of it. I know of a visiting professor at an American University [sic] who, trying to teach APL, bitterly complained about the absence of APL terminals. He was clearly unable to teach it without them. And you, too, write to me that you would like to meet me in your part of the world, so that you can “demonstrate APL” to me. This is in sharp contrast to people who prefer programming languages that can be adadequately [sic] “demonstrated”—i.e. shown, taught and discussed—with pencil and paper.
* A typical characteristic of the APL devotee is, for instance, his closeness to an implementation of it. I know of a visiting professor at an American University [sic] who, trying to teach APL, bitterly complained about the absence of APL terminals. He was clearly unable to teach it without them. And you, too, write to me that you would like to meet me in your part of the world, so that you can “demonstrate APL” to me. This is in sharp contrast to people who prefer programming languages that can be adadequately [sic] “demonstrated”—i.e. shown, taught and discussed—with pencil and paper.


A further comment is recorded by [[Alan Perlis]]<ref>Perlis, Alan. [https://www.jsoftware.com/papers/perlis78.htm Almost Perfect Artifacts Improve only in Small Ways: APL is more French than English]</ref>:
A further comment is recorded by [[Alan Perlis]]<ref>[[Alan Perlis|Perlis, Alan]]. [https://www.jsoftware.com/papers/perlis78.htm Almost Perfect Artifacts Improve only in Small Ways: APL is more French than English]</ref>:


{{Quote|What [Fritz Bauer] saw or heard was Ken’s remark that APL is an extremely appropriate language for teaching algebra, and he muttered under his breath to me, in words I will never forget, “As long as I am alive, APL will never be used in Munich.” And Dijkstra, who was sitting on my other side, leaned toward Bauer and said, “Nor in Holland.” The three of us were listening to the same lecture, but we obviously heard different things.}}
{{Quote|What [Fritz Bauer] saw or heard was Ken’s remark that APL is an extremely appropriate language for teaching algebra, and he muttered under his breath to me, in words I will never forget, “As long as I am alive, APL will never be used in Munich.” And Dijkstra, who was sitting on my other side, leaned toward Bauer and said, “Nor in Holland.” The three of us were listening to the same lecture, but we obviously heard different things.}}
Line 67: Line 67:
* [https://www.jsoftware.com/papers/TAOaxioms.htm "TAO Axioms"]
* [https://www.jsoftware.com/papers/TAOaxioms.htm "TAO Axioms"]


Dijkstra laments the inability of APL programmers to live without an APL session: an odd criticism, as the first APL session, [[APL\360]], was released years after the publication of [[A Programming Language]], and created at a time when [[Iverson Notation]] had already been used to teach mathematics and design IBM hardware. In fact it is common for APLers to communicate verbally, on a blackboard, or on paper without using an APL session; [[Aaron Hsu]] is known for combining his use of APL with a love of calligraphy and fountain pens in order to fill notebooks<ref>Hsu, Aaron. [https://www.sacrideo.us/paper-is-dead-long-live-paper-programming/ "Paper is dead, long live Paper Programming"]</ref>. Among mathematically inclined APLers, the session is often considered an aid in constructing a correct proof rather than a goal in itself. As an "executable mathematical notation" APL is both suited for expressing the final result and for verifying with examples that the steps of the proof are correct.
Dijkstra laments the inability of APL programmers to live without an APL session: an odd criticism, as the first APL session, [[APL\360]], was released years after the publication of [[A Programming Language]], and created at a time when [[Iverson Notation]] had already been used to teach mathematics and design IBM hardware. In fact it is common for APLers to communicate verbally, on a blackboard, or on paper without using an APL session; [[Aaron Hsu]] is known for combining his use of APL with a love of calligraphy and fountain pens in order to fill notebooks<ref>[[Aaron Hsu|Hsu, Aaron]]. [https://www.sacrideo.us/paper-is-dead-long-live-paper-programming/ "Paper is dead, long live Paper Programming"]</ref>. Among mathematically inclined APLers, the session is often considered an aid in constructing a correct proof rather than a goal in itself. As an "executable mathematical notation" APL is both suited for expressing the final result and for verifying with examples that the steps of the proof are correct.


One specific complaint that Dijkstra levels at APL is its use of an expanded set of operations relative to the typical set used in computer science research. It's true that APL dedicates much of its functionality to working with arrays, but this shouldn't be taken as a theoretical weakness. In fact, APLs array operators are much like structured programming, which eliminates a single construct, Go to, in favor of several branching and looping constructs like ''if'' and ''while''. Moving from scalar processing to array processing requires new operations in exchange for, not at the expense of, improved theoretical properties. Nonetheless, language designers such as [[Arthur Whitney]] put considerable effort into reducing the number of symbols needed in the language in order to express ideas. Indeed, [[Fred Brooks]] praised [[Ken Iverson|Iverson]] for a "fierce determination not to invent any new constructs, until you have to."<ref>Brooks, Fred. ''A Celebration of Kenneth Iverson'' ([https://www.jsoftware.com/papers/KEIQA.htm#touchstone excerpt])</ref>
One specific complaint that Dijkstra levels at APL is its use of an expanded set of operations relative to the typical set used in computer science research. It's true that APL dedicates much of its functionality to working with arrays, but this shouldn't be taken as a theoretical weakness. In fact, APLs array operators are much like structured programming, which eliminates a single construct, Go to, in favor of several branching and looping constructs like ''if'' and ''while''. Moving from scalar processing to array processing requires new operations in exchange for, not at the expense of, improved theoretical properties. Nonetheless, language designers such as [[Arthur Whitney]] put considerable effort into reducing the number of symbols needed in the language in order to express ideas. Indeed, [[wikipedia:Fred Brooks|Fred Brooks]] praised [[Ken Iverson|Iverson]] for a "fierce determination not to invent any new constructs, until you have to."<ref>Brooks, Fred. ''A Celebration of Kenneth Iverson'' ([https://www.jsoftware.com/papers/KEIQA.htm#touchstone excerpt])</ref>


Dijkstra pointed out that APL is not used in practice for theoretical computer science applications. This is likely to be cultural: because of the requirement that published papers be readable by most practicing theorists, computer scientists tend to use languages or [[wikipedia:Psuedocode|pseudocode]] which is kept deliberately simple and uses only the well-known programming features. Nonetheless there are array languages or languages with array influence aimed at theoretical work, such as [[FP]], [[FL]], [[Nial]], and [[Futhark]]. APL concepts such as the [[Scan]] operator have also been adopted in the study of parallel programming.<ref>Blelloch, G.E. [https://ieeexplore.ieee.org/document/42122 "Scans as primitive parallel operations"] </ref> [[Aaron Hsu]] has made heavy use of APL in studying parallel algorithms in [[Co-dfns]], and emphasizes its transparent performance characteristics: time and space complexity can usually be obtained directly from an APL expression with little effort.
Dijkstra pointed out that APL is not used in practice for theoretical computer science applications. This is likely to be cultural: because of the requirement that published papers be readable by most practicing theorists, computer scientists tend to use languages or [[wikipedia:Psuedocode|pseudocode]] which is kept deliberately simple and uses only the well-known programming features. Nonetheless there are array languages or languages with array influence aimed at theoretical work, such as [[wikipedia:FP (programming language)|FP]], [[Nial]], and [[Futhark]]. APL concepts such as the [[Scan]] operator have also been adopted in the study of parallel programming.<ref>Blelloch, G.E. [https://ieeexplore.ieee.org/document/42122 "Scans as primitive parallel operations"] </ref> [[Aaron Hsu]] has made heavy use of APL in studying parallel algorithms in [[Co-dfns]], and emphasizes its transparent performance characteristics: time and space complexity can usually be obtained directly from an APL expression with little effort.


Dijkstra claims that APL is a "bag of tricks" which encourages the programmer to think of problems as merely puzzles which require them to find the correct trick rather than to approach them by trying to express their ideas elegantly. An APLer would probably conclude that he has fallen into the trap of thinking of APL as a [[domain-specific language]] which just happens to have the right solution for the particular problem under consideration. Iverson thought instead that APLs tricks are carefully selected tools which guide programmers to more elegant solutions, and elegance is a primary concern for APL programmers today. This comment may also reflect a lack of introspection by Dijkstra into his own working methods and those of other mathematicians: mathematicians work by applying high-level concepts, techniques, or tricks, and write proofs by translating these tricks into mathematical language. APL aids a mathematician's thinking by supplying a well-considered set of techniques, and eases reading by making the "tricks" explicit rather than forcing the reader to extract them from a low-level notation.
Dijkstra claims that APL is a "bag of tricks" which encourages the programmer to think of problems as merely puzzles which require them to find the correct trick rather than to approach them by trying to express their ideas elegantly. An APLer would probably conclude that he has fallen into the trap of thinking of APL as a [[domain-specific language]] which just happens to have the right solution for the particular problem under consideration. Iverson thought instead that APLs tricks are carefully selected tools which guide programmers to more elegant solutions, and elegance is a primary concern for APL programmers today. This comment may also reflect a lack of introspection by Dijkstra into his own working methods and those of other mathematicians: mathematicians work by applying high-level concepts, techniques, or tricks, and write proofs by translating these tricks into mathematical language. APL aids a mathematician's thinking by supplying a well-considered set of techniques, and eases reading by making the "tricks" explicit rather than forcing the reader to extract them from a low-level notation.
Line 79: Line 79:
Dijkstra's paper "Go To Statement Considered Harmful" was an important factor in the introduction of structured programming, which in APL has led to the addition of [[control structure]]s and encouraging their use in favor of the [[branch]] command. Papers on [https://link.springer.com/chapter/10.1007/3-540-07131-8_25 APLGOL] and [https://www.researchgate.net/publication/262210729_Design_of_a_structured_APL SAPL], two experiments in bringing structured programming to APL in the 1970s, both reference Dijkstra's work.
Dijkstra's paper "Go To Statement Considered Harmful" was an important factor in the introduction of structured programming, which in APL has led to the addition of [[control structure]]s and encouraging their use in favor of the [[branch]] command. Papers on [https://link.springer.com/chapter/10.1007/3-540-07131-8_25 APLGOL] and [https://www.researchgate.net/publication/262210729_Design_of_a_structured_APL SAPL], two experiments in bringing structured programming to APL in the 1970s, both reference Dijkstra's work.


Marshall Lochbaum cites [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1300.html EWD1300], "The notational conventions I adopted, and why", and in particular the notion of spacing to represent precedence, as an influence on the design of [[I]].<ref>Lochbaum, Marshall. [https://github.com/mlochbaum/ILanguage/blob/master/doc/influences.md "I's influences"]</ref>
[[Marshall Lochbaum]] cites [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1300.html EWD1300], "The notational conventions I adopted, and why", and in particular the notion of spacing to represent [[precedence]], as an influence on the design of [[I]].<ref>[[Marshall Lochbaum|Lochbaum, Marshall]]. [https://github.com/mlochbaum/ILanguage/blob/master/doc/influences.md "I's influences"]</ref>


== External links ==
== External links ==
Line 89: Line 89:


<references />
<references />
{{DEFAULTSORT:Dijkstra}}[[Category:People]]

Navigation menu