2,951
edits
Edsger W. Dijkstra: Difference between revisions
Jump to navigation
Jump to search
m
Remove "domain-specific language" links; not clear this merits an article
No edit summary |
m (Remove "domain-specific language" links; not clear this merits an article) |
||
| Line 19: | Line 19: | ||
Dijkstra didn't hate APL specifically: he hated every language other than [[wikipedia:ALGOL 60|ALGOL 60]]. However, APL has been the target of specific criticism in a number of his correspondences (which are called EWDs, after Dijkstra's initials): | Dijkstra didn't hate APL specifically: he hated every language other than [[wikipedia:ALGOL 60|ALGOL 60]]. However, APL has been the target of specific criticism in a number of his correspondences (which are called EWDs, after Dijkstra's initials): | ||
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD295.html EWD295]: Iverson was walgelijk, dit was een “slick commercial” over APL. Het weerzinwekkendst vond ik zijn grofheid jegens zijn publiek. Als het zijn bedoeling is geweest om APL te verkopen, dan is hij hierdoor niet geslaagd: het publiek accepteerde hem niet. Ik kan het ontwerp geen consistentie ontzeggen (zal dat ook niet doen), wat op het eerste gezicht alleen maar ad-hoccery lijkt, blijkt meestal op een of andere manier overwogen. Het heeft mijn indruk bevestigd dat de invloed van APL op zijn gebruikers funest is: it is a giant bag of tricks! En inplaats van dat het de neiging programmeren te zien als puzzlen bestrijdt, moedigt het gereedschap deze opvatting aan. Ik dacht —en geloof dit nog— dat programmeren in de eerste plaats een conceptuele uitdaging is en zie niet, hoe APL in dit opzicht een stap vooruit is. Het treft mij zelfs als een stap achteruit.<br/>''Translated with [https://www.DeepL.com/Translator deepl], with edits:''<br/>Iverson was disgusting. This was a "slick commercial" about APL. The most disgusting thing I found was his rudeness towards his audience. If his intention was to sell APL, he didn't succeed: the public wouldn't accept him. I can't deny (or won't deny) the design consistency, which at first glance seems only ad-hoccery, and is usually considered in some way. It has confirmed my impression that the impact of APL on its users is disastrous: it's a giant | * [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD295.html EWD295]: Iverson was walgelijk, dit was een “slick commercial” over APL. Het weerzinwekkendst vond ik zijn grofheid jegens zijn publiek. Als het zijn bedoeling is geweest om APL te verkopen, dan is hij hierdoor niet geslaagd: het publiek accepteerde hem niet. Ik kan het ontwerp geen consistentie ontzeggen (zal dat ook niet doen), wat op het eerste gezicht alleen maar ad-hoccery lijkt, blijkt meestal op een of andere manier overwogen. Het heeft mijn indruk bevestigd dat de invloed van APL op zijn gebruikers funest is: it is a giant bag of tricks! En inplaats van dat het de neiging programmeren te zien als puzzlen bestrijdt, moedigt het gereedschap deze opvatting aan. Ik dacht —en geloof dit nog— dat programmeren in de eerste plaats een conceptuele uitdaging is en zie niet, hoe APL in dit opzicht een stap vooruit is. Het treft mij zelfs als een stap achteruit.<br/>''Translated with [https://www.DeepL.com/Translator deepl], with edits:''<br/>Iverson was disgusting. This was a "slick commercial" about APL. The most disgusting thing I found was his rudeness towards his audience. If his intention was to sell APL, he didn't succeed: the public wouldn't accept him. I can't deny (or won't deny) the design consistency, which at first glance seems only ad-hoccery, and is usually considered in some way. It has confirmed my impression that the impact of APL on its users is disastrous: it's a giant bag of tricks! And instead of fighting against seeing programming as a puzzle, the tool encourages this view. I thought —and still believe this— that programming is first and foremost a conceptual challenge, and I don't see how APL is a step forward in this respect. It even strikes me as a step backwards. | ||
* [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html EWD340] In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the [[one-liner]]s”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in [[Code golf|less symbols]]?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. | * [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html EWD340] In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the [[one-liner]]s”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in [[Code golf|less symbols]]?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. | ||
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD385.html EWD385]: I am afraid that the result is a disaster, at least for German Computing Science. German Computing Science is in danger of being taken over either by the mathematicians or by APL; in both cases the result will be very much the same, viz. the end of German Computing Science! [See also [[APL-Germany]]] | * [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD385.html EWD385]: I am afraid that the result is a disaster, at least for German Computing Science. German Computing Science is in danger of being taken over either by the mathematicians or by APL; in both cases the result will be very much the same, viz. the end of German Computing Science! [See also [[APL-Germany]]] | ||
| Line 73: | Line 73: | ||
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 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 | 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. | ||
== Influence == | == Influence == | ||