Setting aside the the elephant in the room (modern coding LLMs are in some sense indeed compilers for natural language -- except they still "compile to" ordinary programming languages) it nonetheless seems to me that even conventional programming languages use too little, not too much, natural language.
Example:
- "&&" rather than "and",
- "||" rather than "or",
- "if (A) B" rather than "if A then B"
This only makes the code harder to read for beginners without apparent benefit. I'm not sure whether Dijkstra would have agreed.
Thankfully though, programming languages already use mostly explicit (English) language in function names. Which is a much better situation than in mathematics, where almost every function or operator is described by a single nondescript letter or symbol, often even in Greek or in a weird font style.
There is a tradeoff between conciseness and readability. Mathematics has decided long ago to exclusivly focus on the former, and I'm glad this didn't happen with programming. If we read Dijkstra as arguing that only focusing on readability (i.e., natural language) is a bad tradeoff, then he is right.
Truly a treasure trove … unfortunately, much of the wisdom from people like Dijkstra seems to have been forgotten or ignored by the software engineering industry.
Something which I occasionally link to, is this: <https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF>. It not only shows why computer languages should start their indexes at 0 (instead of 1), but also shows why intervals should be specified as lower-inclusive and upper-exclusive.
Positions in sequences like arrays are referred to using ordinal numbers (first, second, third, ...). There is no ordinal "zeroth". Ordinal numbers start at 1. This is contrary to cardinal ("how many?") numbers, which start at 0. And talking of "natural" numbers is besides the point. Therefore, referring to the seventh element in a sequence with the name "6" rather than "7" is confusing and provokes off-by-one errors.
I once had one of his quote on the back of my business card when I was doing a lot of software dev consultancy: "Computer Science is no more about computers than astronomy is about telescopes".
I keep meaning to sit down with this site and make my way through it all. Might make more progress if I grab them into an eReader-friendly format and then peruse them more easily when travelling.
Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
...
The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
...
Projects promoting programming in "natural language" are intrinsically doomed to fail.
Answers to questions from students of Software Engineering
[The approximate reconstruction of the questions is left as an exercise to the reader.]
...
No, I'm afraid that computer science has suffered from the popularity of the Internet. It has attracted an increasing —not to say: overwhelming!— number of students with very little scientific inclination and in research it has only strengthened the prevailing (and somewhat vulgar) obsession with speed and capacity.
Yes, I share your concern: how to program well —though a teachable topic— is hardly taught. The situation is similar to that in mathematics, where the explicit curriculum is confined to mathematical results; how to do mathematics is something the student must absorb by osmosis, so to speak. One reason for preferring symbol-manipulating, calculating arguments is that their design is much better teachable than the design of verbal/pictorial arguments. Large-scale introduction of courses on such calculational methodology, however, would encounter unsurmountable political problems.
As I'm currently in a Functional Programming course in Haskell... This resonated.
I know that we'll always need to write programs which directly interface with memory.
However, when we don't need to do that... Maybe we shouldn't write programs in this style (i.e. imperative). Maybe we shouldn't even use an imperative language (I know, that's a stretch, many languages have incorporated functional aspects and we can utilize them instead of trying to avoid the language entirely).
---
Dijkstra ends EWB 32 with:
"Smoothly we have arrived at the third component of our tool, viz. the language: also the language should be a reliable one. In other words it should assist the programmer as much as possible in the most difficult aspect of his task, viz. to convince himself —and those others who are really interested— that the program he has written down defines indeed the process he wanted to define."
"As my very last remark I should like to stress that the tool as a whole should have still another quality. It is a much more subtle one; whether we appreciate it or not depends much more on our personal taste and education and I shall not even try to define it. The tool should be charming, it should be elegant, it should be worthy of our love. This is no joke, I am terribly serious about this. In this respect the programmer does not differ from any other craftsman: unless he loves his tools it is highly improbable that he will ever create something of superior quality."
At the same time these considerations tell us the greatest virtues a program can show: Elegance and Beauty."
---
Functional languages... help us achieve these aims.
Also the burn in the beginning of EWD899 (not transcribed) is noteworthy:
A review of a paper in AI.
I read "Default Reasoning as Likelihood Reasoning" by Elaine Rich. (My copy did not reveal where it had been published; the format suggests some conference proceedings. If that impression is correct, I am glad I did not attend the conference in question.
Seeing book sections or chapters starting with zero, always confuses me. I know that this convention is probably inspired by the fact that the addresses of memory locations start with zero. But that case was due to that fact one of the combination of the voltages can be all zeros. So, it's actually the count of combinations, and I don't think it can be used for ordinal enumeration of worldly things such as book chapters, or while talking about the spans in space and time (decades, centuries, miles etc). There is no zeroth century, there is no zeroth mile and there is no zeroth chapter. In case the chapter numbers are not meant be ordinal, then I think it would be odd to call Chapter 3 as fourth chapter.
Completely silly fact: knowing 0 about the guy except that he gave his name to the famous algorithm, I had somehow assumed he was Indian. Weird to see a white Dutchman in the picture.
> As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language
Dijkstra already wrote this in the 80s and today many teachers still complain about this fact. I also know that, at least in the Netherlands, the curriculum is judged based on the percentage of students that pass. If too few students pass, then the material is made easier (never harder!), so you can imagine what happens if this process continued for half a century by now.
the only meaningful contribution this guy made was his prose. certainly a talented constructor of sentences, i could never write as precisely as him.
but as far as meaningful technical contributions, i struggle to find anything. his path search algorithm, no offence, is self-evident.
for all the disdain he appears to have had for (what we now call) the 'move fast and break things' style of engineering/science, they were the ones that gave us everything today. you innovate by running experiments, not philosophising and writing proofs.
in retrospect he probably should have stayed on his initial discipline, theoretical physics.
The most charitable thing i can say about your comment is;
who had a fashion of calling every thing "odd" that was beyond his comprehension, and thus lived amid an absolute legion of "oddities." -- from "The Purloined Letter" by Edgar Allan Poe.
To dismiss you/your comment;
“Mediocrity knows nothing higher than Itself; but Talent instantly recognizes Genius.” -- from "The Valley of Fear" by Arthur Conan Doyle.
To deflate your claim of Dijkstra's Algorithm being "self-evident";
Always fascinating how Dijkstra’s writings feel just as relevant today. His clarity of thought on simplicity and structure in code still sets a standard we rarely reach.
23 comments
[ 4.6 ms ] story [ 49.8 ms ] threadOn the foolishness of "natural language programming". https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
Example:
- "&&" rather than "and",
- "||" rather than "or",
- "if (A) B" rather than "if A then B"
This only makes the code harder to read for beginners without apparent benefit. I'm not sure whether Dijkstra would have agreed.
Thankfully though, programming languages already use mostly explicit (English) language in function names. Which is a much better situation than in mathematics, where almost every function or operator is described by a single nondescript letter or symbol, often even in Greek or in a weird font style.
There is a tradeoff between conciseness and readability. Mathematics has decided long ago to exclusivly focus on the former, and I'm glad this didn't happen with programming. If we read Dijkstra as arguing that only focusing on readability (i.e., natural language) is a bad tradeoff, then he is right.
Positions in sequences like arrays are referred to using ordinal numbers (first, second, third, ...). There is no ordinal "zeroth". Ordinal numbers start at 1. This is contrary to cardinal ("how many?") numbers, which start at 0. And talking of "natural" numbers is besides the point. Therefore, referring to the seventh element in a sequence with the name "6" rather than "7" is confusing and provokes off-by-one errors.
I keep meaning to sit down with this site and make my way through it all. Might make more progress if I grab them into an eReader-friendly format and then peruse them more easily when travelling.
Some meditations on Advanced Programming
https://www.cs.utexas.edu/~EWD/transcriptions/EWD00xx/EWD32....
As I'm currently in a Functional Programming course in Haskell... This resonated.
I know that we'll always need to write programs which directly interface with memory.
However, when we don't need to do that... Maybe we shouldn't write programs in this style (i.e. imperative). Maybe we shouldn't even use an imperative language (I know, that's a stretch, many languages have incorporated functional aspects and we can utilize them instead of trying to avoid the language entirely).
---
Dijkstra ends EWB 32 with:
"Smoothly we have arrived at the third component of our tool, viz. the language: also the language should be a reliable one. In other words it should assist the programmer as much as possible in the most difficult aspect of his task, viz. to convince himself —and those others who are really interested— that the program he has written down defines indeed the process he wanted to define."
"As my very last remark I should like to stress that the tool as a whole should have still another quality. It is a much more subtle one; whether we appreciate it or not depends much more on our personal taste and education and I shall not even try to define it. The tool should be charming, it should be elegant, it should be worthy of our love. This is no joke, I am terribly serious about this. In this respect the programmer does not differ from any other craftsman: unless he loves his tools it is highly improbable that he will ever create something of superior quality."
At the same time these considerations tell us the greatest virtues a program can show: Elegance and Beauty."
---
Functional languages... help us achieve these aims.
https://medium.com/@acidflask/this-guys-arrogance-takes-your...
Also the burn in the beginning of EWD899 (not transcribed) is noteworthy:
A review of a paper in AI. I read "Default Reasoning as Likelihood Reasoning" by Elaine Rich. (My copy did not reveal where it had been published; the format suggests some conference proceedings. If that impression is correct, I am glad I did not attend the conference in question.
https://www.cs.utexas.edu/~EWD/ewd08xx/EWD899.PDF
A while back someone posed EWD765 for an alternate solution, I don't recall if any other solution was found. That was my introduction to these.
[717]: https://www.cs.utexas.edu/~EWD/ewd07xx/EWD717.PDF
[765]: https://www.cs.utexas.edu/~EWD/ewd07xx/EWD765.PDF
Less likely to make mistakes if you can’t erase
Dijkstra already wrote this in the 80s and today many teachers still complain about this fact. I also know that, at least in the Netherlands, the curriculum is judged based on the percentage of students that pass. If too few students pass, then the material is made easier (never harder!), so you can imagine what happens if this process continued for half a century by now.
but as far as meaningful technical contributions, i struggle to find anything. his path search algorithm, no offence, is self-evident.
for all the disdain he appears to have had for (what we now call) the 'move fast and break things' style of engineering/science, they were the ones that gave us everything today. you innovate by running experiments, not philosophising and writing proofs.
in retrospect he probably should have stayed on his initial discipline, theoretical physics.
who had a fashion of calling every thing "odd" that was beyond his comprehension, and thus lived amid an absolute legion of "oddities." -- from "The Purloined Letter" by Edgar Allan Poe.
To dismiss you/your comment;
“Mediocrity knows nothing higher than Itself; but Talent instantly recognizes Genius.” -- from "The Valley of Fear" by Arthur Conan Doyle.
To deflate your claim of Dijkstra's Algorithm being "self-evident";
Students Struggle with Concepts in Dijkstra's Algorithm -- https://dl.acm.org/doi/fullHtml/10.1145/3632620.3671096
Edsger Dijkstra contributed to;