Differences between version 3 and previous revision of GoToStatementConsideredHarmful.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 3 | Last edited on Tuesday, November 11, 2003 4:46:37 pm | by AristotlePagaltzis | Revert |
| Older page: | version 2 | Last edited on Friday, October 24, 2003 2:56:14 am | by AristotlePagaltzis | Revert |
@@ -9,9 +9,9 @@
''Reprinted from Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148. Copyright © 1968, Association for Computing Machinery, Inc. This is a digitized copy derived from an ACM copyrighted work. It is not guaranteed to be an accurate copy of the author's original work.''
----
-For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of GoTo statements in the programs they produce. More recently I discovered why the use of the GoTo statement has such disastrous effects, and I became convinced that the GoTo statement should be abolished from all "higher level" ProgrammingLanguages
(i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.
+For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of GoTo statements in the programs they produce. More recently I discovered why the use of the GoTo statement has such disastrous effects, and I became convinced that the GoTo statement should be abolished from all "higher level" [ProgrammingLanguage]s
(i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.
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.
