Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GOTOphobia considered harmful in C

blog.joren.ga

Post reply on HN
Print view View original

211–220 of 319 posts

Re: GOTOphobia considered harmful in C

#211

Post by dheera »

mort96 wrote: post #140
arp242 wrote: post #77

Earlier quoted context omitted.

The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…

To give people some kind of an idea of what it was created in response to: Imagine writing an entire program in one single main function. The only thing you're allowed to do for flow control is goto. You can do 'goto somelabel;' for an unconditional goto, or you can do 'if (somecondition) goto somelabel;' for a conditional goto. Here's some examples of how it would look if if translated to something C-like: Loops wou…

Not too far from assembly ...

Re: GOTOphobia considered harmful in C

#212

Post by dcow »

rmckayfleming wrote: post #57
owisd wrote: post #26

> On the other hand, today we have the very opposite situation: programmers not using goto when it's appropriate and abusing other constructs, what ironically makes code only less readable. One I see all the time from beginners is creating a finite state machine using one method per state and jumping between states by calling the next state’s method from within the current state’s method. Essentially just emulating g…

This is one of those problems that Tail Call Elimination cleanly addresses. The "obvious" approach to writing an FSM does exactly what you'd expect.

Not if you don't know how to write in only tail calls. Try explaining tail call elimination to one of these programmers learning how to write a state machine (=

Re: GOTOphobia considered harmful in C

#213

Post by klyrs »

bombolo wrote: post #164
Closi wrote: post #104

Earlier quoted context omitted.

Worth also noting the sort of wild limits with Basic too that are partially responsible for the code being spaghetti, including effectively an inability to add new lines in the code without adding a goto between previous statements.

What are you talking about? gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again.

So many hours of my childhood. Wasted. Damn you. Why didn't you tell me about this then?

Re: GOTOphobia considered harmful in C

#214

Post by dcow »

kentonv wrote: post #176
bhawks wrote: post #130

Earlier quoted context omitted.

Even if the standard consolidated on one way or another to pack up secondary exceptions (or discard them) how likely is the calling code going to be able to handle and recover from this case? I am personally on team crash - I would rather my program exited and restarts in a known state then being in some weird and hard to replicate configuration.

So, I personally prefer to use exceptions for "panic" scenarios, like assertion failures, where the application has hit a state it doesn't expect and cannot handle. Crashing makes sense in these scenarios if the application is only doing one thing. But I am usually working on multi-user servers. I would rather fail out the current request, but allow concurrent requests from other clients to continue. Yes, I understan…

> Moreover, crashing on assertions has the unintended consequence of making programmers afraid to write assertions. In a past life, when I worked on C++ servers...

The client side rendition of this philosophy exists too. Some client engineers consider it bad form to allow the user to see the application crash. So much so that they'll actually advocate for harmful things like littering the codebase with default values so that when something bad happens the application just keeps on chugging along in a state that nobody every accounted for because doing who knows what to the user's data because they hid errors in default values. It's really really sloppy.

I am definitely team let the user see the crash. Then they know something went wrong, can be alert, and try again in needed. They can report the problem so the devs are aware or the dev's crash tooling will automatically do it. And, ultimately, the issue will get fixed.

(The original version of this philosophy was probably "don't let the user see the app crash, handle the error properly, showing something helpful to the user if necessary, instead". But when adopted by time-constrained product engineering teams, sadly nobody cares about properly handling error states.)

Re: GOTOphobia considered harmful in C

#215

Post by ernst_klim »

Recently I've had an argument with somebody bragging about they managed to bypass goto with writing following mess:

    do {
      r = allocate_resource();
      if (!r)
        break;
    } while (false);
When I've said that this is just a messy unreadable version of goto, I was told that goto is harmful and this is a structured programming, which is superior. GOTOphobia is real.

Re: GOTOphobia considered harmful in C

#217

Post by josephg »

jjav wrote: post #97
arp242 wrote: post #77

Earlier quoted context omitted.

The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…

> The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. Can't highlight this enough. The type of spaghetti code "goto considered harmful" was reacting to is basically impossible to create anymore, so anyone who didn't work on that type of code in the 80s or earlier probably hasn't seen it. And thus, is applying the mantra "goto considered harmfu…

> The type of spaghetti code "goto considered harmful" was reacting to is basically impossible to create anymore, so anyone who didn't work on that type of code in the 80s or earlier probably hasn't seen it.

Its still quite possible in assembly, where goto (JMP) is your only way to do control flow. But I doubt there's many people left who write and maintain large assembly programs. I imagine most programmers reach for C or something higher level as soon as the program becomes non-trivial.

I still use this cute online Intel 4004 simulator sometimes when I teach programming:

http://e4004.szyc.org/

Its a fun challenge for novice or advanced programmers alike to write little programs in assembly for a CPU from 1971. The assembly language[1] is only 45 commands, and you only need a handful of them anyway. The CPU interpreter is simple enough you can literally see it think.

[1] http://e4004.szyc.org/iset.html

Re: GOTOphobia considered harmful in C

#218

Post by benaadams »

myth2018 wrote: post #178

I would include C# too. Most developers I meet don't even know C# supports GOTO.

C# (and Go) have adjusted goto to ensure consistent scoping, avoiding undefined variables, and keeping control flow reducible. So its a much safer and better form of goto than exposed in C/C++, where you can still do weird things without being warned by the language

Re: GOTOphobia considered harmful in C

#219

Post by worthless-trash »

jamiek88 wrote: post #195
deckard1 wrote: post #162

Earlier quoted context omitted.

> comment lines before subroutines would help. That code looks normal to me. I have a ton of BASIC books and magazines. You're talking about a time period before full screen text editors were a thing. It's almost impossible to explain to anyone that didn't have to work with TI-99 BASIC, C64 BASIC, GW-BASIC/BASICA, etc. what it was like. Once you got to QBASIC/QuickBASIC it was done. Life was easy. A few years before…

Wasting RAM on REM’s was just rookie stuff. I remember chasing bytes with short variable names, abbreviated print statements, reducing spaces as much as possible etc. I had like 28k to play with and I was 14 years old!

And we liked it !

Re: GOTOphobia considered harmful in C

#220

Post by _kst_ »

mort96 wrote: post #140
arp242 wrote: post #77

Earlier quoted context omitted.

The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…

To give people some kind of an idea of what it was created in response to: Imagine writing an entire program in one single main function. The only thing you're allowed to do for flow control is goto. You can do 'goto somelabel;' for an unconditional goto, or you can do 'if (somecondition) goto somelabel;' for a conditional goto. Here's some examples of how it would look if if translated to something C-like: Loops wou…

Could be worse.

https://github.com/Keith-S-Thompson/fizzbuzz-c/blob/master/f...

    #include 
    #include 
    int main(void) {
        jmp_buf jb[7];
        volatile int j = 0;
        setjmp(jb[0]);
        volatile int i = 1;
        if (j == 0) setjmp(jb[1]);
        if (j == 1 && i > 100) longjmp(jb[6], 0);
        if (j == 1 && i % 15 == 0) longjmp(jb[4], 0);
        if (j == 1 && i % 3 == 0) longjmp(jb[2], 0);
        if (j == 1 && i % 5 == 0) longjmp(jb[3], 0);
        if (j == 1) printf("%d\n", i);
        if (j == 1) longjmp(jb[5], 0);
        if (j == 0) setjmp(jb[2]);
        if (j == 1) puts("Fizz");
        if (j == 1) longjmp(jb[5], 0);
        if (j == 0) setjmp(jb[3]);
        if (j == 1) puts("Buzz");
        if (j == 1) longjmp(jb[5], 0);
        if (j == 0) setjmp(jb[4]);
        if (j == 1) puts("FizzBuzz");
        if (j == 0) setjmp(jb[5]);
        i ++;
        if (j == 1) longjmp(jb[1], 0);
        if (j == 0) setjmp(jb[6]);
        j ++;
        if (j
Post reply on HN