Programming thread

[y a t s]

imo the main use case for goto is breaking through multiple layers of nested loops, for everything else there's better options

for everything else there's better options

for everything else

I feel like there are way better options for this too. e.g. functions and early returns. If nesting becomes a problem, your function is probably doing way more than it should and you would likely benefit from breaking it up into smaller functions.

Basically, when things get complex, programmers often reach for "return" or "break" or "continue", not because they want to return a value or explicitly need a conditional loop, but because they need "goto" but have been told "goto" is bad (or, worse, their language doesn't have it). This is the same sort of abstraction inversion that gives us things like RAII-instead-of-finally-blocks in C++ or object-with-no-fields-and-a-single-method-instead-of-function-pointer in Java. It's niggerlicious and I cannot take any language that refuses to have gotos (or an explicit equivalent such as tail calls) seriously.

On the contrary, I think your examples are more niggerlicious.

loop_start:
foo = input();
if (len(foo) == 0) goto loop_end;
/* ... do something ... */
goto loop_start
loop_end:

Why? Seriously. Just why?

Which is functionally the same thing, except letting the language create the labels and the goto at the bottom for you, at the cost of the language also creating a conditional branch that always fails (will typically be optimized out, but the cognitive overhead and eyesore remains).

How is this not a more cognitively overloading eyesore than a built-in for or while loop?

/* Attempt to acquire using method 1 */
if (succeeded) goto use;
/* Attempt to acquire using method 2 */
if (succeeded) goto use;
/* Attempt to acquire using method 3, and so on */
if (succeeded) goto use;
/* ... */
use:
/* Complex use of acquired thing */

Why not do

methodOne();
if (success)
    // Return initialized shit here

methodTwo();
if (success)
    // Return initialized shit here

// ...
  
return null;

and have a descriptively named function with the single purpose of initializing/acquiring whatever shit is needed? Why sperg about stack frames and turn your code into spaghetti to avoid them?

Of course, the truly skilled at coping with an insistence on avoiding gotos will factor out all the "acquire" parts into a separate procedure so that they can use "return" to skip over all the remaining methods on success.

>Of course, the truly skilled at being big stupid poopyface morons with an insistence on being retarded will do [SANE THING].

Some of the worst code ever written was the result of someone trying to be overly clever in how they implemented it. Readability is often heavily sacrificed.
As a rule of thumb, don't be clever; be explicit.