Edsger W. Dijkstra: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
Miraheze>Marshall (Created page with ":''This page is about Dijkstra's relationship with APL. For complete information about Dijsktra, see Wikipedia.'' '''Edsger Wybe Dijkstra'''...") |
Miraheze>Marshall mNo edit summary |
||
| Line 1: | Line 1: | ||
:''This page is about Dijkstra's relationship with APL. For complete information about Dijsktra, see [[wikipedia:Edsger W. Dijkstra|Wikipedia]].'' | :''This page is about Dijkstra's relationship with APL. For more complete information about Dijsktra, see [[wikipedia:Edsger W. Dijkstra|Wikipedia]].'' | ||
'''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 43: | Line 43: | ||
{{quote|APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.}} | {{quote|APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.}} | ||
This remark is the last of a list of comments denigrating FORTRAN, PL/I, BASIC, and COBOL, and is followed by a series of negative remarks about the users and developers of programming languages: businesses, the Department of Defense, soft scientists, and physicists. | This remark is the last of a list of comments denigrating FORTRAN, PL/I, BASIC, and COBOL, and is followed by a series of negative remarks about the users and developers of programming languages: businesses, [[IBM]], the Department of Defense, soft scientists, and physicists. | ||
Although Dijkstra does not describe in EWD498 the reasons why he believes APL to be a "mistake" (this section of EWD498 is presented as a list of "truths" which Dijkstra assumes the reader mostly agrees with), we can reach some understanding based on the quotes reproduced above as well as the first of his list of truths: | Although Dijkstra does not describe in EWD498 the reasons why he believes APL to be a "mistake" (this section of EWD498 is presented as a list of "truths" which Dijkstra assumes the reader mostly agrees with), we can reach some understanding based on the quotes reproduced above as well as the first of his list of truths: | ||
| Line 67: | Line 67: | ||
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, [[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| | 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]], [[Niall]], 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. | 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. | ||