> It turns out, the central argument put forth in Dijkstra's paper is that the 'goto' statement messes up the stack trace.
Didn't sit right with my recollection so I reread it, it's brief so I recommend others take the time to read it themselves (I think it's one of those short and easy texts that the vast majority people have heard of and reference without ever having read, so be the change and read it if you haven't).
His central thesis is laid out in paragraphs two and three, with the rest being an attempt at explaining why the go to statement creates problems and his suggested improvement:
> My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.
> My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
In summary, shortening the semantic distance between the static representation and the dynamic execution improves our ability to understand that dynamic execution. And that is critical because it's the actual thing we, as programmers, are producing.
Your statement:
> It turns out, the central argument put forth in Dijkstra's paper is that the 'goto' statement messes up the stack trace.
Didn't sit right with my recollection so I reread it, it's brief so I recommend others take the time to read it themselves (I think it's one of those short and easy texts that the vast majority people have heard of and reference without ever having read, so be the change and read it if you haven't).
His central thesis is laid out in paragraphs two and three, with the rest being an attempt at explaining why the go to statement creates problems and his suggested improvement:
> My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.
> My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
In summary, shortening the semantic distance between the static representation and the dynamic execution improves our ability to understand that dynamic execution. And that is critical because it's the actual thing we, as programmers, are producing.