Edsger W. Dijkstra: Difference between revisions

Jump to navigation Jump to search

Edsger W. Dijkstra (view source)

Revision as of 22:46, 11 November 2019

No change in size ,  22:46, 11 November 2019
→‎Commentary on APL: Reorder EWDs by number since utexas "order by date" is nonsense
Miraheze>Marshall
Miraheze>Marshall
(→‎Commentary on APL: Reorder EWDs by number since utexas "order by date" is nonsense)
Line 20: Line 20:


* [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]:''<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 [[domain-specific language|bag of tricks]]! And instead of 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.
* [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]:''<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 [[domain-specific language|bag of tricks]]! And instead of 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.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD952.html EWD952]: Whereas computing science made great strides towards a vigorous, rigorous discipline, computing practice showed mainly stagnation. I am not exaggerating: the physicists still think that FORTRAN is the last word in computing, the chemists continue with BASIC, and what APL is for the electronic engineer, COBOL is for the MBA.
* [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/EWD04xx/EWD406.html EWD406]: Morris showed me some of his efforts to design a higher programming language that would control that machine: it was a valiant effort, but too much APL'ish to inspire me.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD456.html EWD456]: Two years ago I pondered about the design of an intellectually well-manageable programming language, the implementation of which would allow a potentially very high degree of concurrency without imposing it (nor, of course, requiring the amount of temporary storage that would be needed to simulate the concurrency.) One can try to reach such a goal by the introduction of multi-component datatypes like in APL, but then the price to be paid seems to be a very elaborate repertoire of operations, and, having seen where that leads to, I obviously did not want to go down "that slippery road of reasoning".
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD456.html EWD456]: Two years ago I pondered about the design of an intellectually well-manageable programming language, the implementation of which would allow a potentially very high degree of concurrency without imposing it (nor, of course, requiring the amount of temporary storage that would be needed to simulate the concurrency.) One can try to reach such a goal by the introduction of multi-component datatypes like in APL, but then the price to be paid seems to be a very elaborate repertoire of operations, and, having seen where that leads to, I obviously did not want to go down "that slippery road of reasoning".
* [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/EWD04xx/EWD498.html EWD498]: 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.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html EWD498]: 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.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD633.html EWD633]: I thought "On the Power of Applicative Languages" by R.Lipton and L.Snyder one of the worst [conference talks]: its actual topic, believe me or not, was a study of the space/time complexity of ... APL-one-liners! [See also [[Co-dfns]]]
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD633.html EWD633]: I thought "On the Power of Applicative Languages" by R.Lipton and L.Snyder one of the worst [conference talks]: its actual topic, believe me or not, was a study of the space/time complexity of ... APL-one-liners! [See also [[Co-dfns]]]
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD638.html EWD638]: None of the many papers about program verification and derivation that I have written or seen uses APL as a programming vehicle. This could be an accident, it could also be a consequence of the rich expression structure of APL. (They refer to proofs as "...substitutions to be checked with the aid of simple algebraic identities" which, in the case of APL-expressions are perhaps not so simple...) If the latter conjecture is correct, it would explain why APL-addicts might feel unhappy about (or threatened by) modern achievements in proving the correctness of (non-APL) programs. Does it help the understanding of this paper and its venom to know of the heavy involvement with APL of its authors? We can only guess and have our private opinions.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD638.html EWD638]: None of the many papers about program verification and derivation that I have written or seen uses APL as a programming vehicle. This could be an accident, it could also be a consequence of the rich expression structure of APL. (They refer to proofs as "...substitutions to be checked with the aid of simple algebraic identities" which, in the case of APL-expressions are perhaps not so simple...) If the latter conjecture is correct, it would explain why APL-addicts might feel unhappy about (or threatened by) modern achievements in proving the correctness of (non-APL) programs. Does it help the understanding of this paper and its venom to know of the heavy involvement with APL of its authors? We can only guess and have our private opinions.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD406.html EWD406]: Morris showed me some of his efforts to design a higher programming language that would control that machine: it was a valiant effort, but too much APL'ish to inspire me.
* [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD952.html EWD952]: Whereas computing science made great strides towards a vigorous, rigorous discipline, computing practice showed mainly stagnation. I am not exaggerating: the physicists still think that FORTRAN is the last word in computing, the chemists continue with BASIC, and what APL is for the electronic engineer, COBOL is for the MBA.


APL is far from unique in this respect: complaints about COBOL, FORTRAN, PL/I, LISP, PASCAL, and Ada each outnumber complaints about APL in EWDs, and praise for any of these languages is entirely absent, with the exception of LISP, about which Dijkstra remarks "I must confess that I was very slow on appreciating LISP’s merits"<ref>Dijkstra, E.W. [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html EWD 1284: Computing Science: Achievements and Challenges]</ref>.
APL is far from unique in this respect: complaints about COBOL, FORTRAN, PL/I, LISP, PASCAL, and Ada each outnumber complaints about APL in EWDs, and praise for any of these languages is entirely absent, with the exception of LISP, about which Dijkstra remarks "I must confess that I was very slow on appreciating LISP’s merits"<ref>Dijkstra, E.W. [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html EWD 1284: Computing Science: Achievements and Challenges]</ref>.
Anonymous user
Retrieved from ‘https://aplwiki.com/wiki/Special:MobileDiff/1790’

Navigation menu