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.
I love that essay. It's such a joy to read, and even though it is very short and to the point it says so much both about the topic itself and society at large.
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.
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.
If you’re at a corner and someone asks for directions, you say “three blocks that way”. That means three blocks starting from here.
Then what do you call “here”?
The name for where you start from in this scenario is usually not required because it’s obvious what you mean and everyone understands the first block means you have to first walk a block, not that where you start is the first block.
So in that sense yes we have a zeroth chapter. That’s when you’re at the beginning of the first one but haven’t read all the way.
"here" is definitely not a zeroth block. As soon you start walking, you are in the first block. However, if you are numbering the separations (cuts) between the blocks, you can number that "here" as zero.
Ok as soon as you start walking your are in the first block, I agree. So then where are you before that? What block were you at before you started moving, when you were giving directions?
What is the name of the block from which you left to enter the first block? Before you started walking I mean.
And mustn’t that block be before that other first? When we move from where we start we count up, so then mustn’t an earlier block be counting down? Counting down would mean a number smaller than one.
And are blocks not counted in units, as whole numbers?
So would it not be the case that one block less than 1 must be by necessity the zeroth block?
In other words if you agree that “as soon as you start walking, you are in the first block”, then you must also agree that before you left you began in the zeroth block.
The first element in a collection at address 15 is at address 15. The offset of an element from the start is addr-start, so 15-15=0 for the first, 16-15=1 for the second, etc.
that's why we start from 0, not because of voltages, at least in compsci.
This is all mostly about cuts and spans in a continuum. Cuts can be numbered starting with zero, but spans can't be. Book chapters are spans of content.
Usually the chapter 0 is preliminary or prerequisite material. It makes sense in an obvious and intuitive way if you want an ordinal "before the first", even if that sense isn't a rigorous mathematical one (although I think there's no problem with it).
I guess the practice was influenced by computer science - I don't know of an example that precedes it, but one fairly early one I've found is Bishop and Goldberg's Tensor Analysis on Manifolds from 1968, with a chapter 0 on set theory and topology. Back then the authors felt the need to justify their numbering in the preface:
"The initial chapter has been numbered 0 because it logically precedes the main topics"
Quite straightforward.
There's also the "zeroth law of thermodynamics", which was explicitly identified long after the first, second, and third laws, but was felt more primary or basic, hence the need for an "ordinal before the first"
The reason is that, for an array (or vector), you find the memory position for the i-th element with the base address + i*word_length. And the first element is in the base address - so has index 0.
It has memory offset 0, which we use as the array index for convenience so that there's no distinction between a memory offset-base and the corresponding array index-base. That's what happens when your arrays are barely different from pointers, as in C. If your arrays aren't just a stand-in for raw pointers, then there's little reason to require 0-based indexing. You can use more natural indexes based on your particular application, and many languages do allow arbitrary indices.
Building floor numbers in at least a few countries I’m aware of start from zero or “G” ( or the local language equivalent for “ground“) with 1 being the first story above the ground.
I think you’re just biased to think that starting must “naturally” begin with 1.
Zero is just a good a place to start and some people do start counting from zero.
The floor number case arises so because traditionally it is the count of "built" floors. So, ground is technically not a floor in that sense. Also, if the floor indicates a separation (cut) between the living spaces, ground floor can be numbered as zero, just like the start point of a measuring tape is numbered as zero.
Zero is not an ordinal number. There can be a vector element indexed with zero, but it is not "zeroth" element. Book chapter numbers are ordinal numbers.
Just the convenience of having an ordinal number to say? Rather than saying "chapter 0, chapter 1, chapter 2" one can say "the fourth chapter"? Or is it the fact that the chapter with number 4 has 3 chapters preceding it?
On first glance I find this all rather meaningless pedantry.
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.
I knew an Indian woman named Divya, perhaps my mind thought it looked similar in print?
I don’t think it was ever a conscious decision. It’s similar to how I always pictured Jane Austen as a sarcastic woman in her forties while reading her books, but she wrote her most famous works being borderline a teenager. Your mind just fills things up I guess.
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.
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.
I've read them all. While they are fun to read as their commentary come from a place of logic, there is a lot of emotion baked in and little room for being open minded about potential alternatives that could find their ways to reality. Dijkstra was very smart but you can tell thinking is a little closed, which is not objectively bad, but it happens a little too much for my taste.
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.
Since I've been playing around with AI a lot lately, I'd suggest taking a few papers and uploading them for context...seeing good examples vastly improves their subsequent programming ability.
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.
Alas, I live an a world where efficiency does actually matter, and elegance to me includes efficiency. I live in a world of embedded software, portability, and reliability. In this regard, almost every single functional language is an utter failure, because they require runtimes and big fat common libraries. Even golang is borderline. Haskell has little chance.
Generally I think this does answer the question about why functional languages don't dominate more than they do - although you could make an argument that JavaScript is a functional language, and it certainly is enjoying a lot of dominance these days. JS environments aren't known for being particularly efficient, though. To me, efficient use of resources is elegant, and a language needs to be able to do that.
You brought up something interesting. I believe academic computer science originated from at least three cultures: pure mathematics (Church, Turing, Kleene, Dijkstra), electrical engineering, and psychology (Licklieder). I say “at least” since there may be other cultures I’ve overlooked. These three cultures have different views on programming: the EE-based culture emphasizes taking full advantage of the underlying hardware, the math-based culture emphasizes proof, and the psychology-based culture emphasizes human factors.
The challenge is reconciling these three views of programming: the holy grail is a programming language that is ergonomic and expressive, yet is also amenable to mathematical reasoning and can be implemented efficiently. I wonder if there is a programming language theory version of the CAP theory in distributed systems, where one compares performance, ease of mathematical reasoning about code, and human factors?
I really enjoy having him recall the design of a computer with the first interrupt: https://www.cs.tufts.edu/comp/150FP/archive/edsger-dijkstra/...
The most important one in the context of 2025 is this one:
On the foolishness of "natural language programming". https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
I'm amused at EWD498 - How do we tell truths that might hurt? https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498...
I'd also recommend EWD1305 https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD130...Dijkstra was so based.
This is gold! Thanks.
Thanks for the link. Great read.
Apparently Dijesktra loved using em-dash!
I love that essay. It's such a joy to read, and even though it is very short and to the point it says so much both about the topic itself and society at large.
And its just so obviously correct.
Suffers from philosophical liberalism I'd say
Which leads to the assumption that some people "just" dont want to be better.
This mental framework is how society justifies the superiority of some persons while ignoring the material realities of others.
This framework is the root of classism, the root of racism, the root of elitism and finally it manifesta in individuals as narcissism.
IMHO you are going way way way to far. Far in the weeds.
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.
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.
If you’re at a corner and someone asks for directions, you say “three blocks that way”. That means three blocks starting from here.
Then what do you call “here”?
The name for where you start from in this scenario is usually not required because it’s obvious what you mean and everyone understands the first block means you have to first walk a block, not that where you start is the first block.
So in that sense yes we have a zeroth chapter. That’s when you’re at the beginning of the first one but haven’t read all the way.
Folks ... cardinal and ordinal numbers both have "just so" stories to support them. We're unlikely to eliminate either one of them today.
"here" is definitely not a zeroth block. As soon you start walking, you are in the first block. However, if you are numbering the separations (cuts) between the blocks, you can number that "here" as zero.
Ok as soon as you start walking your are in the first block, I agree. So then where are you before that? What block were you at before you started moving, when you were giving directions?
What is the name of the block from which you left to enter the first block? Before you started walking I mean.
And mustn’t that block be before that other first? When we move from where we start we count up, so then mustn’t an earlier block be counting down? Counting down would mean a number smaller than one.
And are blocks not counted in units, as whole numbers?
So would it not be the case that one block less than 1 must be by necessity the zeroth block?
In other words if you agree that “as soon as you start walking, you are in the first block”, then you must also agree that before you left you began in the zeroth block.
How else could it be interpreted?
The first element in a collection at address 15 is at address 15. The offset of an element from the start is addr-start, so 15-15=0 for the first, 16-15=1 for the second, etc.
that's why we start from 0, not because of voltages, at least in compsci.
This is all mostly about cuts and spans in a continuum. Cuts can be numbered starting with zero, but spans can't be. Book chapters are spans of content.
Usually the chapter 0 is preliminary or prerequisite material. It makes sense in an obvious and intuitive way if you want an ordinal "before the first", even if that sense isn't a rigorous mathematical one (although I think there's no problem with it).
I guess the practice was influenced by computer science - I don't know of an example that precedes it, but one fairly early one I've found is Bishop and Goldberg's Tensor Analysis on Manifolds from 1968, with a chapter 0 on set theory and topology. Back then the authors felt the need to justify their numbering in the preface:
"The initial chapter has been numbered 0 because it logically precedes the main topics"
Quite straightforward.
There's also the "zeroth law of thermodynamics", which was explicitly identified long after the first, second, and third laws, but was felt more primary or basic, hence the need for an "ordinal before the first"
Hopefully they don't discover another more fundamental law, to be called as "minus oneth" law
The reason is that, for an array (or vector), you find the memory position for the i-th element with the base address + i*word_length. And the first element is in the base address - so has index 0.
It has memory offset 0, which we use as the array index for convenience so that there's no distinction between a memory offset-base and the corresponding array index-base. That's what happens when your arrays are barely different from pointers, as in C. If your arrays aren't just a stand-in for raw pointers, then there's little reason to require 0-based indexing. You can use more natural indexes based on your particular application, and many languages do allow arbitrary indices.
Building floor numbers in at least a few countries I’m aware of start from zero or “G” ( or the local language equivalent for “ground“) with 1 being the first story above the ground.
I think you’re just biased to think that starting must “naturally” begin with 1.
Zero is just a good a place to start and some people do start counting from zero.
The floor number case arises so because traditionally it is the count of "built" floors. So, ground is technically not a floor in that sense. Also, if the floor indicates a separation (cut) between the living spaces, ground floor can be numbered as zero, just like the start point of a measuring tape is numbered as zero.
A zeroeth century sounds reasonable to me.
There is however the zeroth element of a vector in most programming languages.
Zero is not an ordinal number. There can be a vector element indexed with zero, but it is not "zeroth" element. Book chapter numbers are ordinal numbers.
But what is there to gain with this distinction?
Just the convenience of having an ordinal number to say? Rather than saying "chapter 0, chapter 1, chapter 2" one can say "the fourth chapter"? Or is it the fact that the chapter with number 4 has 3 chapters preceding it?
On first glance I find this all rather meaningless pedantry.
If I use ordinal numbers to count, then counting tells me the number of objects. Sometimes I want to know the number of objects.
EDIT: Yeah, I don't know why book chapter labels can't start with "0". It seems fine to me. They could use letters instead of numbers for all I care.
Dijkstra wrote a rather famous screed against 1-based indexing, so it's more of an inside joke.
You're also wrong about there being no 0th mile. https://www.atlasobscura.com/places/u-s-route-1-mile-0-sign
I was taught at UT. Apparently Djikstra would make his students take exams with pens instead of pencils.
Less likely to make mistakes if you can’t erase
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.
(Curious) How did Edsger Dijkstra sound like an indian name to you?
I knew an Indian woman named Divya, perhaps my mind thought it looked similar in print?
I don’t think it was ever a conscious decision. It’s similar to how I always pictured Jane Austen as a sarcastic woman in her forties while reading her books, but she wrote her most famous works being borderline a teenager. Your mind just fills things up I guess.
I love the timeless ”Threats to computer science” https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD898...
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
For the mathematically inclined, EWD717 and EWD765 have two really cool problems.
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
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.
Astronomy is not named "Telescope Science" though. ;-)
This is a treasure (it’s been around quite a while). For those youngers out there: still completely relevant. Still ahead of the game, imho.
I've read them all. While they are fun to read as their commentary come from a place of logic, there is a lot of emotion baked in and little room for being open minded about potential alternatives that could find their ways to reality. Dijkstra was very smart but you can tell thinking is a little closed, which is not objectively bad, but it happens a little too much for my taste.
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.
Since I've been playing around with AI a lot lately, I'd suggest taking a few papers and uploading them for context...seeing good examples vastly improves their subsequent programming ability.
I really enjoyed the this one:
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.
Alas, I live an a world where efficiency does actually matter, and elegance to me includes efficiency. I live in a world of embedded software, portability, and reliability. In this regard, almost every single functional language is an utter failure, because they require runtimes and big fat common libraries. Even golang is borderline. Haskell has little chance.
Generally I think this does answer the question about why functional languages don't dominate more than they do - although you could make an argument that JavaScript is a functional language, and it certainly is enjoying a lot of dominance these days. JS environments aren't known for being particularly efficient, though. To me, efficient use of resources is elegant, and a language needs to be able to do that.
You brought up something interesting. I believe academic computer science originated from at least three cultures: pure mathematics (Church, Turing, Kleene, Dijkstra), electrical engineering, and psychology (Licklieder). I say “at least” since there may be other cultures I’ve overlooked. These three cultures have different views on programming: the EE-based culture emphasizes taking full advantage of the underlying hardware, the math-based culture emphasizes proof, and the psychology-based culture emphasizes human factors.
The challenge is reconciling these three views of programming: the holy grail is a programming language that is ergonomic and expressive, yet is also amenable to mathematical reasoning and can be implemented efficiently. I wonder if there is a programming language theory version of the CAP theory in distributed systems, where one compares performance, ease of mathematical reasoning about code, and human factors?