Earlier this year, Perl programmer and author Mark Jason Dominus mentioned in an e-mail list that the 1974 paper "Structured Programming with go to Statements," by Donald E. Knuth, was one of his favorite computer science papers. I printed a copy and have been carrying it in my briefcase, unread, since then. I finally got a chance to read it on an airplane this week. I found it to be amazingly informative and entertaining, and I wanted to share a bit of it with you.

By the time I encountered Fortran 77 in my freshman year at Georgia Tech in 1982, the transition to structured programming was pretty much a done deal. Also, since I was in electrical engineering and not computer science, I did not learn anything at the time about the evolution of programming languages. So I was fascinated to read Knuth's perspective on the transition to structured programming, written as the transition was happening. I was also very interested to see how many themes that still concern and guide software developers today are mentioned by Knuth in this 1974 paper.

Knuth discusses in detail various techniques for eliminating go to statements in some illustrative algorithms, considering efficiency, readability, safety, etc. He looks at mechanical transformation techniques and compares proposed programming language features such as event indicators and different looping constructs. He considers a case involving multiway branching where he regards the go to as beneficial.

But his remarkable collection of asides and almost parenthetical observations fascinates me the most. Let me share a few choice bits with you.

Knuth introduces his paper with three quotes:

You may go when you will go, And I will stay behind. —Edna St. Vincent Millay
Most likely you go your way and I'll go mine. —Song title by Bob Dylan
Do you suffer from painful elimination? —Advertisement, J. B. Williams Co.

Knuth on the sometimes heated nature of the go to discussions:

In fact, the discussion has apparently caused some people to feel threatened; Dijkstra once told me that he actually received "a torrent of abusive letters" after publication of his article.

I was curiously comforted to discover that even legendary programmers can have trouble adjusting to new ideas:

I remember feeling frustrated on several occasions, at not seeing how to write programs in the new style; I would run to Bob Floyd's office asking for help, and he usually showed me what to do.

Knuth on some proposed alternatives to go to that don't really change anything:

Other go to-less languages for system programming have similarly introduced other statements which provide "equally powerful" alternative ways to jump. In other words, it seems that there is widespread agreement that go to statements are harmful, yet programmers and language designers still feel the need for some euphemism that "goes to" without saying go to.

Knuth's famous quote about premature optimization in context:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

On avoiding code duplication:

[Copying common code] would be a pointless waste of energy just to eliminate a perfectly understandable go to statement: the resulting program would actually be harder to maintain than the former, since the action of printing a character now appears in two difference places.

On a pitfall of code comments:

Accompanying comments explain the program, [but] it is easy to make mistakes, partly because we rely so much on comments which might possibly be inaccurate descriptions of what the program really does.

Skepticism of quantitative metrics:

But there has been far too much emphasis on go to elimination instead of the really important issues; people have a natural tendency to set up an easily understood quantitative goal like the abolishment of jumps, instead of working directly for a qualitative goal like good program structure.

Programming puns about the 1960s:

I discussed [a] weakness of ALGOL in a letter to Niklaus Wirth in 1967, and he proposed two solutions to the problem, together with many other instructive ideas in an unpublished report on basic concepts of programming languages. His first suggestion was to write
  repeat begin S; when B exit; T; end
and readers who remember 1967 will also appreciate his second suggestion,
  turn on begin S; when B drop out; T; end

On teaching programming:

I have always felt that the transformation from recursion to iteration is one of the most fundamental concepts of computer science, and that a student should learn about it at about the same time he is studying data structures. [...] It surprises me that the literature on recursion removal is primarily concerned with "baby" examples like computing factorials or reversing lists [...]

On table-driven logic:

Multiway branching is an important programming technique which is all too often replaced by an inefficient sequence of if tests. Peter Naur recently wrote me that he considers the use of tables to control program flow as a basic idea of computer science that has been nearly forgotten; but he expects it will be ripe for rediscovery any day now. It is the key to efficiency in all the best compilers I have discovered.

On flowcharts:

As an undergraduate, in 1959, I published an octopus flowchart which I sincerely hope is the most horribly complicated that will ever appear in print; anyone who believes that flowcharts are the best way to understand program flow is urged to look at this example.

And finally, I learned that the joke about using come from instead of go to dates back to at least R. Lawrence Clark in 1973.

If you ask me about the possibility of go to in MATLAB, I'll simply direct you to Loren's April 1 2006 post on the subject.