Viewing a single comment thread. View all comments

tezoatlipoca t1_iyahosc wrote

Its not necessarily, if used correctly. PRoblem is it was arbitrary and prone to abuse; it is (or was, no one uses it anymore) lazy programming in languages higher than assembly.

Usually we want to branch code execution based on some criteria.

IF condition THEN
 do these things
OTHERWISE
 do other things
END IF 
do some necessary cleanup

This way there's a controlled return from the branching. We only have two routes: do these things or the other things. There are no other options or possible routes for execution.

By controlling or containing the execution this way we know that regardless of whether we do these things or other things, we'll ALWAYS wrap up afterward with the necessary cleanup (which might be really important.)

If I throw a random GOTO in there,

IF condition THEN
 do these things
OTHERWISE
 do other things
 GOTO XANADU
END IF 
do some necessary cleanup

#XANADU 
 do some unrelated stuff
 get lost

unless I explicitly end that goto with another GOTO that returns me to where I left off, I might never return. We'll never do the necessary cleanup for example.

Using GOTOs allowed you to jump ANYwhere. I could jump into the middle of other branches I could jump out of loops willy nilly; yeah, this is still allowed with break statements but at least the break statement just exits the loop, a GOTO could warp you anywhere. So very powerful... but it also lets programmers be lazy. Code getting too complicated? Can't find a way to structure it properly so error and failure cases return you to someplace sane? Meh, bash a GOTO in there. Its like a magic code ticket that takes you to where you want to go with no (and by that I mean all the) consequences (unallocaed memory, initialized/uninitialized variables, who knows).

A GOTO is like a magic airline ticket that takes you anywhere in the world. Except when you get there you may not have any luggage. Or both feet.

139

Megalocerus t1_iyb9mpc wrote

In COBOL the goto didn't even have to specify the destination. You could do an ALTER and have it go somewhere else. Try reading that.

GOTOs are bad but ALTER is Satanic.

15

carlovski99 t1_iyc60gq wrote

Or even worse, comefrom https://en.m.wikipedia.org/wiki/COMEFROM

2

Megalocerus t1_iydadd3 wrote

Yes, that's far worse, but I never encountered that in real code. The rules for using alter were:

  1. Don't use it.

  2. If you use it, have any GOTO referenced by it leave off the destination in code. Thus, it was just GOTO. by itself on the line with a period, to clue the programmer it was a trap.

1

Existing-Metal-5211 t1_iydidtc wrote

Naw... I did some stuff like that in basic by poking the basic code with destination. I cannot recall why I didn't use on goto for that project tho.

1

Intergalacticdespot t1_iyc1xkw wrote

If you're writing BASIC (well apple][e/c64 era basic) it's not. You don't really have a choice. Now...probably is and not sure what youd even use it for other than some lazy hackish stuff.

2

AustinJeeper t1_iyb0jrq wrote

sooooo, function() ?

i think the main issue is more like

  • IF condition Then
    • do this stuff
    • #Xanadus
      • do some shit
    • do shit only needed at fall through
  • Else
    • other stuff
  • end if

#goto Xanadu

it lead to horrible references.

−1

Nagisan t1_iybirhz wrote

> sooooo, function() ?

Not exactly.

Functions return to the point of execution once they finish running, GOTO just continues running the program linearly from where ever in the code the GOTO is pointing to.

For example, if the comment you replied to used a function instead of GOTO XANADU, the 'unrelated stuff' would run, then it would return to the spot it left off on, which would run the 'necessary cleanup'. But GOTO doesn't do that, GOTO would run the 'unrelated stuff' and then just hit the end of the file and never clean up.

GOTO is a one-way operation that sends the program to another line of code and never returns (unless you explicitly program another GOTO that goes back), functions send the program to another line of code but then return back to the line the function is called from once the function is done.

9

Deadmist t1_iycdnze wrote

Functions ^1 also give you a well defined arguments, return type(s) and scope for variables.
With GOTO, there is no guarantee for anything.

^1 in most languages, looking at you JS...

2

A_dudeist_Priest t1_iydg0si wrote

I am an old fart developer that learned on the old PET's, C64 and TI, the language I learned on, was BASIC\Waterloo BASIC (we are talking early 80's here), GOTO was a staple. I have watched languages go from a "wall of code", to the more structured OOP that we use today.

You brought up and interesting point that I had never thought of, when calling a Function\Subroutine, everything in the calling function is pushed onto the stack, then popped from the stack when returning from the called function, the GC would then "clean up" as you say. But I guess using a GOTO statement would not push and pop the stack, would/could this cause a modern application to have a memory leak, or cause the application to run out of process and/or Heap space?

A hint for beginner developers, be careful of recursive function calls (functions that call themselves) if done improperly, you get into a recursive loop and you will very quickly run out of stack space.

1

Nagisan t1_iydgn4p wrote

I would guess it could cause memory leak issues and such, but in all honesty I'm not much for low-level programming details beyond what I did through school and much prefer sticking around the web dev space these days....so I'm not entirely sure the full implications that GOTO would have on memory.

1

generous_cat_wyvern t1_iybqmwc wrote

>functions send the program to another line of code but then return back to the line the function is called from once the function is done.

Except for when Exceptions are thrown, but I guess that's why they're called Exceptions :p (I actually don't know if that's the reason, I probably just made that up) But even Exceptions propagate up a call stack in a predictable manner.

As an aside, it blew my mind when I found out that in ASP.NET, redirects happen by internally throwing a ThreadAbortException behind the scenes that can't be handled by normal means. It made sense that code after calling redirect didn't execute, and the only way to have code behave that way is if an Exception is thrown, I just never put two and two together.

0

Nagisan t1_iybrn9u wrote

Exceptions can open up a whole pandora's box in the flow of a program. I can't speak for every language (because there's lots I don'tknow), but at least with what I'm most familiar with the function does return to the line it was called from depending on how you handle the exception.

In the case of your function catching the exception, you can fail gracefully by logging an error, at which point the program will continue and the function will return to the line that called it then just chug right along (if the result of the function wasn't necessary for the program to continue).

In the case your function doesn't catch the exception, it will bubble up to the place it was called from and repeat this process (if the exception is caught at the higher level, my second paragraph happens, otherwise it bubbles up again, repeat until something catches the exception or the program reaches the main function and crashes).

So yeah, exceptions can be the oddity here, but they also can continue to work the same as no exceptions when it comes to the flow through a program.

1