Edsger W. Dijkstra: Difference between revisions
Jump to navigation
Jump to search
langauges => languages
Miraheze>Adám Brudzewsky |
(langauges => languages) |
||
| Line 50: | Line 50: | ||
{{quote|Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.}} | {{quote|Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.}} | ||
Dijkstra believed that the most important task for a programmer was to produce provably correct programs. Many of his works emphasize the use of handwritten mathematical proofs produced alongside programs, although he also contributed to the development of automated theorem proving systems. The most important factor in his judgment of programming | Dijkstra believed that the most important task for a programmer was to produce provably correct programs. Many of his works emphasize the use of handwritten mathematical proofs produced alongside programs, although he also contributed to the development of automated theorem proving systems. The most important factor in his judgment of programming languages was its amenability to and encouragement of formal proofs, and he saw APL as a failure in this regard. Dijkstra held that the ease of use of early APL sessions relative to other programming systems was actually an anti-feature: the ability for programmers—even those without a strong grasp of computer science or mathematics—to interactively develop programs led to a failure to develop proper programming technique and poorer programs. | ||
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. | 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. | ||