3 ms·

Try as I might, I just don't see why it's important to maintain an independent index into the process progress of a running program. So you can know the exact p

Try as I might, I just don't see why it's important to maintain an independent index into the process progress of a running program. So you can know the exact point in the process progress where n equals the number of people in the room minus 1... What is the usefulness of it? What problem does it help solve to have this kind of process coordinate in time? I can understand that unbridled use of GOTO tends to lead to a mess, but Dijkstra's argument seems to be more about the purity of the process, for... some purpose I can't fathom. Still, I imagine he'd have a field day trashing dependency injection and dynamic dispatch!

AnimalMuppet 7y ago
If you've ever had to deal with the previous mess in all its unbridled impurity, you'd know why Dijkstra cares about the purity of the process. The answer wasn't to use GOTO a little bit less, or a little more carefully. That wasn't going to work. The answer was to eliminate it, root and branch.
mcguire 7y ago
Ok, I'm not sure I understand your question, but I'll try... Think of his "index" as a virtual program counter, while you are trying to write the code or understand what someone else has written. At some point, the process is going to be in a state where someone has entered the room (i.e. n = #people - 1), and at a later point you have incremented n (so that n = #people again). One of the key features of Dijkstra's thinking about how to understand and write programs is that you should be thinking about the text of the program, not its dynamic behavior. You should not be "pretending to be the computer"---when you mentally "execute" the program, you have to keep a finger pointed at the current statement (and procedures, recursion, loops, etc., make that pretty difficult). However, I don't know if he'd fully developed that idea in 1968; this article reads like he was still trying to understand programs by playing out their behavior. So, if you were counting people going into a room, at some point you will have seen someone go in, but not have incremented the counter while after the next statement you have seen someone and have incremented the counter. Without a lot of discipline, GOTO has the power to completely throw away whatever understanding of the program you have; you could GOTO that point where you are going to increment the count but without seeing anyone go into the room.
harrygallagher4 7y ago
(note: everything I'm about to say is just my take on early CS stuff, I don't know Dijkstra or how he thought, these are just conclusions I've personally drawn from reading about the history of computing) I think it's hard to imagine because it comes from the mindset of those who pioneered programming, like Dijkstra. You're right that he seemed to be concerned about the 'purity' of the process. It's clear from reading the original article that he (and others) thought about programming in a much more 'mathematical' way than modern people. Dijkstra wanted a program to be clearly defined and computable all the way through, but when you're jumping around the code arbitrarily that's... difficult. All of this comes from the fact that computing was birthed from mathematics, and the people involved in it back then were more likely to have a base in math.

AnimalMuppet 7y ago

If you've ever had to deal with the previous mess in all its unbridled impurity, you'd know why Dijkstra cares about the purity of the process. The answer wasn't to use GOTO a little bit less, or a little more carefully. That wasn't going to work. The answer was to eliminate it, root and branch.

mcguire 7y ago

Ok, I'm not sure I understand your question, but I'll try... Think of his "index" as a virtual program counter, while you are trying to write the code or understand what someone else has written. At some point, the process is going to be in a state where someone has entered the room (i.e. n = #people - 1), and at a later point you have incremented n (so that n = #people again). One of the key features of Dijkstra's thinking about how to understand and write programs is that you should be thinking about the text of the program, not its dynamic behavior. You should not be "pretending to be the computer"---when you mentally "execute" the program, you have to keep a finger pointed at the current statement (and procedures, recursion, loops, etc., make that pretty difficult). However, I don't know if he'd fully developed that idea in 1968; this article reads like he was still trying to understand programs by playing out their behavior. So, if you were counting people going into a room, at some point you will have seen someone go in, but not have incremented the counter while after the next statement you have seen someone and have incremented the counter. Without a lot of discipline, GOTO has the power to completely throw away whatever understanding of the program you have; you could GOTO that point where you are going to increment the count but without seeing anyone go into the room.

harrygallagher4 7y ago

(note: everything I'm about to say is just my take on early CS stuff, I don't know Dijkstra or how he thought, these are just conclusions I've personally drawn from reading about the history of computing) I think it's hard to imagine because it comes from the mindset of those who pioneered programming, like Dijkstra. You're right that he seemed to be concerned about the 'purity' of the process. It's clear from reading the original article that he (and others) thought about programming in a much more 'mathematical' way than modern people. Dijkstra wanted a program to be clearly defined and computable all the way through, but when you're jumping around the code arbitrarily that's... difficult. All of this comes from the fact that computing was birthed from mathematics, and the people involved in it back then were more likely to have a base in math.