To Jump or Not To Jump?

The argument about the admissibility of one or another language construction in programming is much like the attempts to establish an official standard in natural languages. Excluding the "four-letter" words from the dictionary will not prevent people from using them. And the much abused word "goto" still occupies an important place in higher-level programming, despite all the attempts to eliminate it...

Well, what can be said against it except the abstract attribution to "bad style programming"? Yes, one can write a quite incomprehensible program with labels all over without any obvious reason. But the programs without jumps can be as incomprehensible, as soon as we go beyond the trivial cases. The "goto" statement is accused to circumvent the regular clean up procedures of each block; however, this is rather the problem of poor translators than poor programming. The adepts of structural programming say that there is no coherent structure in the programs with jumps; this is mere reflection of their self-restriction to very primitive structures. Some people even declare that using the "goto" is incompatible with programming as a kind of industrial engineering; this is at least strange, since the industry has long since developed with conditional and non-conditional jumps, and this has never been a serious obstacle. Moreover, why only industrial programming should have right to exist? The art of programming is as important component of the human culture.

In the background, on the level of hardware, jump commands are built in the processor, which would be useless without the possibility of switching to a different sequence of commands. Theoretically, one could construct a processor based on closed blocks and events, but this would be nothing but the cumbrous implementation of the simple logic; indeed, event processing implies passing control to the event handler, and this basic functionality cannot be changed by coding it in the processor chip rather than commands in memory. The branching commands are universal, they do not depend on the processor type, since they are related to the very logic of sequential processing, and any processing at all develops in time and hence has a sequential component. The attempts to eliminate time from programming are like eliminating food from eating.

Of course, there are classes of tasks where time is not inherent. For instance, to solve a differential equation, one does not necessarily need to do it step by step, if there is a parallel procedure allowing to do it in one step (like in analog computers). Adaptive computers would be able to solve a wide range of problems without strict algorithmization. However, when it comes to modeling and automation of workflow, sequential processing cannot be avoided.

In the structural approach, a program is a collection of blocks A, B, ... , with each block being a closed unit, which, once initiated by an event, has to be completed as a whole. That is flow control is reduced to the only construction:

The major problem with jumps comes from exaggerated reusability of the code. When one can jump into a block, do something, and then jump out, there is a risk of encountering unitialized objects or memory leakage due to creation of objects that are never destroyed. But the same problems arise in the languages without jumps (one could point to frequent memory leaks in Java programs as a typical example). It is a strange kind of logic, to devoid programmers of a powerful tool just because some of them cannot properly use it.

It can be argued, whether one should be able to enter a block in multiple entry points, or only at the beginning, and how the block should be left. For instance, in a multithreaded process, each block can be considered as a thread, and hence there is nothing strange in that another thread communicates with only a few of its components. This is how real things interact. On the other side, if a block is a kind of class, and each call requires instantiation, it is up to the translator, to interpret multiple entry points as a single entry point with parameters, and premature exit as a branch to the termination handler.