“Program slicing” is automatically breaking up computer code into parts either to optimize code by running only what’s needed or to break into pieces for others to optimize.
But The GOTO (or Jump) was difficult for program slicing as it wasn’t nice and modular and in blocks like non-GOTO programs. Many theoretical program slicers were developed that just pretended GOTO would never be encountered and the few that did would only allow certain kinds of GOTO.
Yet, the compiler doesn’t have an issue with GOTO if the language supports the function. In fact, compilers use GOTO-equivalent statements in making bytecode and computers jump around as needed while running programs “at the metal” level.
But way back up at the high levels, GOTO is considered “Dangerous”. But really, it’s just icky, not dangerous. Style.
Supposedly, it’s hardly in use in production. 40 years of being told GOTO IS BAD in programming classes, programming languages devoid of the GOTO have tried to eliminate it entirely and many have. In collaborative programming, which is what much of programming is, any programmer who might want to use a goto style statement when it’s going to be looked at by peers may hesitate in fear of being mocked.
But what I find interesting is, going back to program slicing: is the difficulty of it.
I think I found a few that succeeded in slicing code with GOTO and I’ll look at them as they may have some lessons to be learned about dealing with the kind of randomness that one encounters throughout a day, where GOTO is a living reality and life is not structured.