Code Read 2 - Dijkstra on Goto

Edsger W. Dijkstra, a giant of computer science, wrote an article long ago arguing that the "goto" statement was bad for programmers and the programs they wrote. Week 2 of Code Reads covers this article.

The statement "goto is bad" is exactly the kind of attention getting statement that provokes internecine fights between partisans of various languages. Unfortunately, the flame-wars usually miss the most relevant points. I'm definitely in the "no silver bullet" school, in fact I'm in a sub-sect of that school that says "your choice of language in and of itself is almost irrelevant to the success of the project". Obviously, Logo would be an inappropriate choice of language for building a web site, and for parsing log files Perl is a lot easier than Java. But the chief benefits of one language or another are using the skills of the people available, fitting in with a larger organization, and the availability of tools and libraries suitable for the job, not the language constructs.

So if language constructs are less than relevant, what is the point of Dijkstra's article? I found Joel Neely's comments in the Code Reads discussion section particularly insightful: the problem with "goto" is that it breaks the metaphors we develop to organize our code.

Dijkstra himself makes this fairly clear:

"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." - EWD

I take this to mean that code is not the end goal here - correct execution is the goal. Or to use modern language - the business logic must solve the business problem. That should be the focus of our activities, not the code itself.

"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." - EWD

Although Dijkstra is saying a lot more than just this, the key point here is that we should make sure that the way we build a program bears a simple correspondence to the way it works, and more specifically, to a way we can think about it.

Which brings us back to the chief problem with "goto" statements - they tend to obscure the underlying logic of the program, instead of making it more apparent. They may make writing code marginally easer but that make building software much more difficult.