Edsger W. Dijkstra: Difference between revisions

:''This page is about Dijkstra's relationship with APL. For more complete information about Dijsktra, see [[wikipedia:Edsger W. Dijkstra|Wikipedia]].''

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>

Iverson: <math>++/(M=\iota^1\begin{smallmatrix}∘\\+\end{smallmatrix}\iota^1)//M</math>

* [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.

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>:

It's also possible that the reference to "the programming techniques of the past" refers to the use of [[branch]] for control flow. This criticism is now irrelevant: modern APL programming uses [[control structures]] like all mainstream languages. Indeed, APL's use of [[reduction]]s and the [[Each]] and [[Outer Product]] operators can be seen as a step beyond structured programming in moving from imperative to functional structure. This technique has become common in the 2010s, but APLs use of these operators in the 1980s and 90s was well ahead of its time.

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. 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>

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'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 structures]] 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>