When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all the dirty low level assembler code (for sorts and other area's in which speedup was huge over COBOL). Was shown how my approach was far more wasteful of CPU resources and why others would not be able to maintain such code as all the rest used GOTO's. I will admit, it was nicely explained and this is in a time in which mainframes offered the only computer solutions for business of this scale and not cheap.
I will say GOTO's work well for exception handerling, but still doable without. But for speed, though less of a factor today, it still translates as faster code at the low level of CPU runs.
But then, things move on and you will always have that wave of what students are taught being cutting edge compared to what is actualy in use in work. A friction many would have encountered in one form or another, even today. Be it style, design or language/tools choice. What is the best today, may well be outdated tomorrow, but you have to maintain that legacy investment and it is often too costly/risky to rewrite that legacy for something that itself could be legacy the next day.
So as for harmful, well they can spagetti up code if used badly, yet that comes to many approaches and if they are that bad, why do CPU's still have JUMP instructions you could counter-argue.
> why do CPU's still have JUMP instructions you could counter-argue
Machine code is linear and executed one instruction at a time. It does not have the concept of blocks, so there is no way to have structured programming. Jumps are the only way to create a loop or conditional.
Are there normal coding patterns that are much faster with explicit gotos? Modern compilers seem to do a pretty good job of converting normal (goto-less) code into efficient binaries.
E.g, the simple switch statement has several possible machine-code implementations that compilers will switch (heh) between, depending on the characteristics of the cases.
In bytecode interpreter VMs, one often encounters the "computed goto" [1] pattern in use to dispatch opcodes. This is one that tends to be a little faster than a switch statement, enough to matter in the dispatch inner loop.
Of course, if you are going to JIT compile the bytecode, that'll usually be a lot faster. But at that point you're changing one form of low-level wizardry for another.
I will say GOTO's work well for exception handerling, but still doable without. But for speed, though less of a factor today, it still translates as faster code at the low level of CPU runs.
But then, things move on and you will always have that wave of what students are taught being cutting edge compared to what is actualy in use in work. A friction many would have encountered in one form or another, even today. Be it style, design or language/tools choice. What is the best today, may well be outdated tomorrow, but you have to maintain that legacy investment and it is often too costly/risky to rewrite that legacy for something that itself could be legacy the next day.
So as for harmful, well they can spagetti up code if used badly, yet that comes to many approaches and if they are that bad, why do CPU's still have JUMP instructions you could counter-argue.
Oh and well played on the humour.