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.

 

[snotang]

Why? Seriously. Just why?

I believe I already explained why: it accomplishes what you cannot do by putting the actual test directly inside the condition part of a "while" statement. It is true that most programmers will find the "while(1)" form far more familiar, and therefore easier to read. It also avoids the necessity of choosing names. I am not advocating for goto maximalism. I am saying that there are things that are needlessly difficult without them, and it is absurd for a general-purpose programming language to omit them.

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?

Because this is just goto with extra steps. If you have a good reason to factor out the code, factor it out. If it's because you need a label to jump to but are scared of four letters, that's stupid. If the code in question needs to access and/or modify variables in the enclosing scope, you'll likely need to complicate the interface to your new procedure to the point that it will significantly increase the confusion of anyone trying to read it. Now any control flow involving the containing procedure needs to be serialized into some sort of (documented) return value, then deserialized back into control flow.

And, of course, you have to think of a name, and that's just as much a point against procedures as it is against labels. Even greater, in fact, since most people only create global procedures, and they are typically lexically farther-removed from their point of reference.

>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.

If you can't jump to a label but can jump to the end of a procedure, and you need to jump to a target, the natural solution is to make a procedure whose end is your target. It is an entirely reasonable solution to an entirely unreasonable problem that people create for themselves. It is a testament to how ingrained that stylistic choice is that one could consider pushing an address onto the stack followed by popping it into the PC register to be "explicit" compared to jumping to the address directly, which is "overly clever".

I mean this seriously, take a step back and look at how you are framing this. Not adding an extra level of indirection is so unthinkable to you that you have decided that it counts as turning your code into spaghetti solely for the sake of not adding an extra level of indirection. This doesn't happen anywhere else. Nobody wonders why isdigit takes int instead of int* or why malloc returns void* instead of void**. There's just no good reason not to do it that way. How can we even explain this response other than as a social phenomenon?

 

[Least Concern]

i think arrays should take indices that are unicode strings

arr[] = 60;
arr[] = 7;
int i = [arr[] + arr[

];
cout << i; //67

PHP gotchu, fam.

Of course, nobody actually writes code like that.

PHP has labels and goto too, though I've never used them nor seen anyone else use them.

 

[Fat Camp Intern]

Not adding an extra level of indirection is so unthinkable to you that you have decided that it counts as turning your code into spaghetti solely for the sake of not adding an extra level of indirection.

I literally, just now, encountered a situation where a goto would have been perfect. Instead, I had to twist and contort the control flow around the lack of the feature.

snotang is 100% right here.

 

[y a t s]

Now any control flow involving the containing procedure needs to be serialized into some sort of (documented) return value, then deserialized back into control flow.

And why is this a necessarily bad thing? Why are you seemingly allergic to shit that helps people quickly make sense of what you wrote?

Because this is just goto with extra steps. If you have a good reason to factor out the code, factor it out. If it's because you need a label to jump to but are scared of four letters, that's stupid. If the code in question needs to access and/or modify variables in the enclosing scope, you'll likely need to complicate the interface to your new procedure to the point that it will significantly increase the confusion of anyone trying to read it.

If you can't jump to a label but can jump to the end of a procedure, and you need to jump to a target, the natural solution is to make a procedure whose end is your target. It is an entirely reasonable solution to an entirely unreasonable problem that people create for themselves. It is a testament to how ingrained that stylistic choice is that one could consider pushing an address onto the stack followed by popping it into the PC register to be "explicit" compared to jumping to the address directly, which is "overly clever".

>Gee, scoping and value passing is such a pain. Let's just make everything effectively global in scope and jump around in a single monolithic function instead. It'll be so super cool and fast because muh program counter.

How can we even explain this response other than as a social phenomenon?

idk if you being too stupid/inexperienced to understand good practices and the practical benefits they bring is a social phenomenon. It's a you phenomenon.

 

[Fat Camp Intern]

global in scope and jump around in a single monolithic function

If only there were a word for such a thing... hmmmm ... main(), perhaps?

 

[Rango Dango]

I literally, just now, encountered a situation where a goto would have been perfect. Instead, I had to twist and contort the control flow around the lack of the feature.

snotang is 100% right here.

oh and what was that situation out of curiosity?

 

[Goose the Redeemer]

I was hoping for more thread activity, but this isn't quite what I had in mind. Maybe that old monkey's paw is real after all...

Behold as GCC generates the same output for both a real while loop and a manual goto immitation.
https://godbolt.org/z/fGTWjrPf3 (-O0)
https://godbolt.org/z/4nenMMYTe (-O2)

Yes, you're both very smart for understanding that loops and functions are an abstraction over jumps, the compiler knows this too.

 

[CrunkLord420]

Congrats to everyone whose been spamming reports for days. You've won. He's now thread banned for a week.

 

[Jotch]

Congrats to everyone whose been spamming reports for days. You've won. He's now thread banned for a week.

 

[ADHD Mate]

He might be "the dumbest faggot in the world", but he brought some life into this thread.