eric76 said:

---

CDUB98 said:

---

Quote:

---

abomination of the command GOTO

---

DAMMITT!!

That's how us stupid people got things work.

---

Every computer that I know of uses the equivalent of GOTO's at the assembler level.

Also, GOTO's can be very useful even today.

For example, suppose you have a C function in which several conditions can result in errors. Instead of having to do all of your cleanup every time you need to return, you can put a GOTO to the end of your function, do all of your cleanup, and then return.

Suppose that the function opened five files that need to be closed before returning, instead of having to close them for every possible return, you just have to close them them once at the end leaving less room for errors.

When I was a grad student, I was often the one selected to handle the numerical analysis labs. The worst abuse of GOTO's that I ever saw was when dong the numerical analysis labs one year. One student turned in a program with a GOTO arter almost every line. When I asked about it, the student said that she had dropped the card deck and things got out of order, so she reordered them with GOGO cards instead of sorting them in order.

---

YOU DO WHAT?!

Use micro-scopes!!

Quote:

---

A diagonal marker line across the side of the deck definitely helped with dropped decks....

---

... he says 50+ years late.

eric76 said:

---

CDUB98 said:

---

Quote:

---

abomination of the command GOTO

---

DAMMITT!!

That's how us stupid people got things work.

---

When I was a grad student, I was often the one selected to handle the numerical analysis labs. The worst abuse of GOTO's that I ever saw was when dong the numerical analysis labs one year. One student turned in a program with a GOTO arter almost every line. When I asked about it, the student said that she had dropped the card deck and things got out of order, so she reordered them with GOGO cards instead of sorting them in order.

---

Imagine someone dropping the cards and creating infinite GOTO loops!

flown-the-coop said:

---

Who is Claude?

---

Claude works in the basement!

eric76 said:

---

CDUB98 said:

---

Quote:

---

abomination of the command GOTO

---

DAMMITT!!

That's how us stupid people got things work.

---

Every computer that I know of uses the equivalent of GOTO's at the assembler level.

Also, GOTO's can be very useful even today.

For example, suppose you have a C function in which several conditions can result in errors. Instead of having to do all of your cleanup every time you need to return, you can put a GOTO to the end of your function, do all of your cleanup, and then return.

Suppose that the function opened five files that need to be closed before returning, instead of having to close them for every possible return, you just have to close them them once at the end leaving less room for errors.

---

Newer languages provide an alternative to `goto ERROR` in the form of exceptions and `try`...`catch`, with a `finally` clause (Java), `using` statement (C#), or scoped-based destructors (C++) to handle cleanup.

CDUB98 said:

---

IIIHorn said:

---

Does anyone else remember FORTH?

---

Only the Firth.

---

Firth of Forth.

"Laughing/Crying emoticon"

flown-the-coop said:

---

Who is Claude?

---

Claude is an AI, similar to ChatGPT but more oriented towards software developers. (I have an account through work.)

IIIHorn said:

---

CDUB98 said:

---

IIIHorn said:

---

Does anyone else remember FORTH?

---

Only the Firth.

---

Firth of Forth.

"Laughing/Crying emoticon"

---

I knew you'd get it.

Most of my industry's stock has dropped by 50% over last 6-8 months due to AI takeover concerns.

My options from last year are completely worthless right now.

BonfireNerd04 said:

---

eric76 said:

---

CDUB98 said:

---

Quote:

---

abomination of the command GOTO

---

DAMMITT!!

That's how us stupid people got things work.

---

Every computer that I know of uses the equivalent of GOTO's at the assembler level.

Also, GOTO's can be very useful even today.

For example, suppose you have a C function in which several conditions can result in errors. Instead of having to do all of your cleanup every time you need to return, you can put a GOTO to the end of your function, do all of your cleanup, and then return.

Suppose that the function opened five files that need to be closed before returning, instead of having to close them for every possible return, you just have to close them them once at the end leaving less room for errors.

---

Newer languages provide an alternative to `goto ERROR` in the form of exceptions and `try`...`catch`, with a `finally` clause (Java), `using` statement (C#), or scoped-based destructors (C++) to handle cleanup.

---

Maybe. Many people look down on using try and catch. I think that Google, for example, frowns on their use because they bypass the normal flow of execution.

In C++ at least, the catch is in the calling function, not the function where the error occurred. As such, it would normally be too late to do a cleanup.

From Google's style guidelines:

Quote:

---

Exceptions

We do not use C++ exceptions.

Pros
* Exceptions allow higher levels of an application to decide how to handle "can't happen" failures in deeply nested functions, without the obscuring and error-prone bookkeeping of error codes.
* Exceptions are used by most other modern languages. Using them in C++ would make it more consistent with Python, Java, and the C++ that others are familiar with.
* Some third-party C++ libraries use exceptions, and turning them off internally makes it harder to integrate with those libraries.
* Exceptions are the only way for a constructor to fail. We can simulate this with a factory function or an Init() method, but these require heap allocation or a new "invalid" state, respectively.
* Exceptions are really handy in testing frameworks.

Cons
* When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.
* More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This causes maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand.
* Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it.
* Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure.
* The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!

Decision:

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.

Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.

This prohibition also applies to exception handling related features such as std::exception_ptr and std::nested_exception.

There is an exception to this rule (no pun intended) for Windows code.

---

Scope based destructors can work fine. I use them all the time.

I rarely use GOTO's, but there are times when they can be used to produce much cleaner code than all the machinations you would have through in order to avoid them.

The Firth of Forth...IIIHorn said:

---

CDUB98 said:

---

IIIHorn said:

---

Does anyone else remember FORTH?

---

Only the Firth.

---

Firth of Forth.

"Laughing/Crying emoticon"

---

The Firth of Forth...

eric76 said:

---

BonfireNerd04 said:

---

eric76 said:

---

CDUB98 said:

---

Quote:

---

abomination of the command GOTO

---

DAMMITT!!

That's how us stupid people got things work.

---

Every computer that I know of uses the equivalent of GOTO's at the assembler level.

Also, GOTO's can be very useful even today.

For example, suppose you have a C function in which several conditions can result in errors. Instead of having to do all of your cleanup every time you need to return, you can put a GOTO to the end of your function, do all of your cleanup, and then return.

Suppose that the function opened five files that need to be closed before returning, instead of having to close them for every possible return, you just have to close them them once at the end leaving less room for errors.

---

Newer languages provide an alternative to `goto ERROR` in the form of exceptions and `try`...`catch`, with a `finally` clause (Java), `using` statement (C#), or scoped-based destructors (C++) to handle cleanup.

---

Maybe. Many people look down on using try and catch. I think that Google, for example, frowns on their use because they bypass the normal flow of execution.

In C++ at least, the catch is in the calling function, not the function where the error occurred. As such, it would normally be too late to do a cleanup.

From Google's style guidelines:

Quote:

---

Exceptions

We do not use C++ exceptions.

Pros
* Exceptions allow higher levels of an application to decide how to handle "can't happen" failures in deeply nested functions, without the obscuring and error-prone bookkeeping of error codes.
* Exceptions are used by most other modern languages. Using them in C++ would make it more consistent with Python, Java, and the C++ that others are familiar with.
* Some third-party C++ libraries use exceptions, and turning them off internally makes it harder to integrate with those libraries.
* Exceptions are the only way for a constructor to fail. We can simulate this with a factory function or an Init() method, but these require heap allocation or a new "invalid" state, respectively.
* Exceptions are really handy in testing frameworks.

Cons
* When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.
* More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This causes maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand.
* Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it.
* Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure.
* The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!

Decision:

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.

Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.

This prohibition also applies to exception handling related features such as std::exception_ptr and std::nested_exception.

There is an exception to this rule (no pun intended) for Windows code.

---

Scope based destructors can work fine. I use them all the time.

I rarely use GOTO's, but there are times when they can be used to produce much cleaner code than all the machinations you would have through in order to avoid them.

---

In 30+ years of coding in FORTRAN, I NEVER saw a time when the GOTO wasn't the scourge of the devil and needed to be destroyed.

There was ALWAYS a much cleaner way to do the code (especially since it required whatever place you wanted to go to now required a line number)...

I use nullptr based error handling & small scopes.

Always check a pointer before you use it and always delete a new.

Delete the default constructor to force memory initialization. Maybe include a static counter in construction to track duplicated objects.

So far I've been able to leave GOTO on the TI-89 where it belongs, and I've never been able to justify try-catch over just a memory-dump, reinit, and debug.

Scope any using. Reading code with namespace methods and global using is simply infuriating. Same with macros nested 7+ deep.

Ag with kids said:

---

eric76 said:

---

I rarely use GOTO's, but there are times when they can be used to produce much cleaner code than all the machinations you would have through in order to avoid them.

---

In 30+ years of coding in FORTRAN, I NEVER saw a time when the GOTO wasn't the scourge of the devil and needed to be destroyed.

There was ALWAYS a much cleaner way to do the code (especially since it required whatever place you wanted to go to now required a line number)...

---

The problem with older programming languages wasn't the existence of GOTO. It was the non-existence of other control-flow constructs.

The point of "structured programming" is that something like

while (!valid)
{
month = read_int("Enter a month (1-12): ");

if (month < 1 || month > 12)
{
print("Invalid input. Try again.");
}
else
{
valid = true;
}
}

is easier to read and maintain than

100 INPUT "Enter a month (1-12): "; MONTH
110 IF MONTH >= 1 AND MONTH <= 12 THEN GOTO 140
120 PRINT "Invalid input. Try again."
130 GOTO 100
140 ' ... rest of program

After the keywords while, do, for, switch, break, continue, return, throw, try, and catch (or the equivalent) are added to a language, there's just not much need for "goto" anymore.

BonfireNerd04 said:

---

Ag with kids said:

---

eric76 said:

---

I rarely use GOTO's, but there are times when they can be used to produce much cleaner code than all the machinations you would have through in order to avoid them.

---

In 30+ years of coding in FORTRAN, I NEVER saw a time when the GOTO wasn't the scourge of the devil and needed to be destroyed.

There was ALWAYS a much cleaner way to do the code (especially since it required whatever place you wanted to go to now required a line number)...

---

The problem with older programming languages wasn't the existence of GOTO. It was the non-existence of other control-flow constructs.

The point of "structured programming" is that something like

while (!valid)
{
month = read_int("Enter a month (1-12): ");

if (month < 1 || month > 12)
{
print("Invalid input. Try again.");
}
else
{
valid = true;
}
}

is easier to read and maintain than

100 GOTO 110
110 GOTO 120
120 GOTO 130
130 GOTO 140
140 GOTO 100

After the keywords while, do, for, switch, break, continue, return, throw, try, and catch (or the equivalent) are added to a language, there's just not much need for "goto" anymore.

---

fify

Ag with kids said:

---

eric76 said:

---

BonfireNerd04 said:

---

eric76 said:

---

CDUB98 said:

---

Quote:

---

abomination of the command GOTO

---

DAMMITT!!

That's how us stupid people got things work.

---

Every computer that I know of uses the equivalent of GOTO's at the assembler level.

Also, GOTO's can be very useful even today.

For example, suppose you have a C function in which several conditions can result in errors. Instead of having to do all of your cleanup every time you need to return, you can put a GOTO to the end of your function, do all of your cleanup, and then return.

Suppose that the function opened five files that need to be closed before returning, instead of having to close them for every possible return, you just have to close them them once at the end leaving less room for errors.

---

Newer languages provide an alternative to `goto ERROR` in the form of exceptions and `try`...`catch`, with a `finally` clause (Java), `using` statement (C#), or scoped-based destructors (C++) to handle cleanup.

---

Maybe. Many people look down on using try and catch. I think that Google, for example, frowns on their use because they bypass the normal flow of execution.

In C++ at least, the catch is in the calling function, not the function where the error occurred. As such, it would normally be too late to do a cleanup.

From Google's style guidelines:

Quote:

---

Exceptions

We do not use C++ exceptions.

Pros
* Exceptions allow higher levels of an application to decide how to handle "can't happen" failures in deeply nested functions, without the obscuring and error-prone bookkeeping of error codes.
* Exceptions are used by most other modern languages. Using them in C++ would make it more consistent with Python, Java, and the C++ that others are familiar with.
* Some third-party C++ libraries use exceptions, and turning them off internally makes it harder to integrate with those libraries.
* Exceptions are the only way for a constructor to fail. We can simulate this with a factory function or an Init() method, but these require heap allocation or a new "invalid" state, respectively.
* Exceptions are really handy in testing frameworks.

Cons
* When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.
* More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This causes maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand.
* Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it.
* Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure.
* The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!

Decision:

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.

Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.

This prohibition also applies to exception handling related features such as std::exception_ptr and std::nested_exception.

There is an exception to this rule (no pun intended) for Windows code.

---

Scope based destructors can work fine. I use them all the time.

I rarely use GOTO's, but there are times when they can be used to produce much cleaner code than all the machinations you would have through in order to avoid them.

---

In 30+ years of coding in FORTRAN, I NEVER saw a time when the GOTO wasn't the scourge of the devil and needed to be destroyed.

There was ALWAYS a much cleaner way to do the code (especially since it required whatever place you wanted to go to now required a line number)...

---

My last Fortran involvement was in about 1982 when I was helping an engineer with his code. I have seen instances in C and C++ in which a GOTO would have improved program flow and comprehension.

And if you get down to it, they all go down to machine code. I've yet to see a machine code/assembly language that isn't full of GOTO's in one manner or another -- they were just under a different name such as BR for branch or JMP for jump.

But, yeah, for normal program control in a modern language, GOTO's are unnecessary. You shouldn't avoid using a GOTO where it is might be useful, though, unless you are very needful of everyone's applause.

Essentially, avoiding using GOTO's under any circumstances is not a whole lot different than political correctness.

NE PA Ag said:

---

COBOL was my least favorite language, that's for sure. FORTRAN was so much easier and forgiving. What was it, 4 defined sections or areas in a COBOL program? One of them was variable definition if I recall correctly.

All the talk about punch cards and dads, my dad was a Chem E major at U of H in the mid 50s and took a computer class as an elective. The problem was they didn't have a mainframe at UH at that point. So Dad and his fellow students would complie their punch cards, put rubber bands around them and put a slip of paper with their names on them. Someone picked them up and drove them to College Station to process on A&M's mainframe, then deliver the results back to the students in Houston the next day.

---

SneakerNet.

eric76 said:

---

Ag with kids said:

---

infinity ag said:

---

Bocephus said:

---

My father (who passed in 2024) is going to be very upset to find his COBOL skills are no longer required.

---

My father who passed in 2023 used to program in Fortran in the mid to late 60s at TI. We still have some of his old punchcards at home.

---

When I first started at LTV in 1992 my computer was in the room that held all the computer cards for both the Near Earth Mission Analysis Routine (NEMAR) and all the input decks for every run they'd ever done. Buttload of filecabinets filled to the brim (the program was probably written before FORTRAN 66).

NEMAR used to take about 2 hrs to run on the VAX when I got there (no more punchcards). When we ported it to a unix system later that year, it ran in 7 seconds. First time, I thought it had failed (did this often because you'd have one digit out of place in the input file and it crapped out).

---

Shortly before April first in 1979, two math undergraduate students had a wonderful idea. They had noticed that the job numbers on the Amdahl 470 (it might have been the IBM 370 instead) were four digits long.

So they wanted to see what would happen if you issued enough stored procedures to run later to take up all of the job numbers. So they create 10,000 card decks, each with about four or five cards.

They had been planning on duplicating the same job card to be used for each job but I pointed out that it might be easy for the computer operator to just eliminate every job with that job card. So I wrote them a routine to generate 1,000 job cards with each having a different code at the start.

April 1 that year was on a Sunday. I would have gone to the RCC to watch the chaos they created, but there was a car race at Texas World Speedway and so I was out there until pretty late (press box staff). When I got back to town, I heard all about it.

When reading a job on the punch card reader, it would pause while checking to make sure that the credentials were correct. This pause was somewhere around a second, if I remember right. They would stick the cards on the the card reader and it would read a few cards, pause, read a few more cards, pause, ... . It took several minutes just to read one box of cards. They probably got a lot of dirty looks from the other students waiting to submit their card decks.

They managed to read in about 7,500 jobs before everything came to a complete halt. The computer was off line for something like an hour before it came back on with all of their jobs cleared off of it.

---

eric76 said:

---

Are there even any COBOL programmers left who are not already at least 65?

---

IIIHorn said:

---

Does anyone else remember FORTH?

---

I remember Fifth. A language an Aggie grad wrote that was used in a robot roaming the halls of Zachary around 1989.

AggieKatie2 said:

---

Most of my industry's stock has dropped by 50% over last 6-8 months due to AI takeover concerns.

My options from last year are completely worthless right now.

---

The options are great, but in my personal experience you can't count on them. I hope you like doing what you do and your team. Good luck.

BonfireNerd04 said:

---

Ag with kids said:

---

eric76 said:

---

I rarely use GOTO's, but there are times when they can be used to produce much cleaner code than all the machinations you would have through in order to avoid them.

---

In 30+ years of coding in FORTRAN, I NEVER saw a time when the GOTO wasn't the scourge of the devil and needed to be destroyed.

There was ALWAYS a much cleaner way to do the code (especially since it required whatever place you wanted to go to now required a line number)...

---

The problem with older programming languages wasn't the existence of GOTO. It was the non-existence of other control-flow constructs.

The point of "structured programming" is that something like

while (!valid)
{
month = read_int("Enter a month (1-12): ");

if (month < 1 || month > 12)
{
print("Invalid input. Try again.");
}
else
{
valid = true;
}
}

is easier to read and maintain than

100 INPUT "Enter a month (1-12): "; MONTH
110 IF MONTH >= 1 AND MONTH <= 12 THEN GOTO 140
120 PRINT "Invalid input. Try again."
130 GOTO 100
140 ' ... rest of program

After the keywords while, do, for, switch, break, continue, return, throw, try, and catch (or the equivalent) are added to a language, there's just not much need for "goto" anymore.

---

Oh...I KNOW why the GOTO existed.

But, as you say, once later versions of FORTRAN existed that supported "ELSE" and "ELSE IF" (which occurred in the release of FORTRAN 77 in....you guessed it...1977) it needed to be erased as quick as possible.

So, I did my duty to do that in the early 2000s...

Now I want to use GOTOs to create a stack of punchcards you can shuffle and still run.

TexasRebel said:

---

Now I want to use GOTOs to create a stack of punchcards you can shuffle and still run.

---

I think this is the villain origin story of Skynet...