I always encourage people to go read Dijkstra's GOTO paper, instead of just its title. It's a short and easy read, almost like a blog post. If you pay attention, you can see that the he was talking about spaghetti code vs structured code. It's better when the lexical structure of the source code maps to the execution structure. That is, if you know what is the current line being executed, you have a good idea of what…
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…
GOTOphobia considered harmful in C
311–319 of 319 posts
Re: GOTOphobia considered harmful in C
#312Earlier quoted context omitted.
> If you're steeped in C and its quirks, have good coding patterns that allow for it, I say knock yourself out. Somewhere between 95% and 100% of people who think they're "steeped in C and its quirks, have good coding patterns that allow for it" write code that invokes undefined behaviour.
There's nothing wrong with undefined behaviour.
Re: GOTOphobia considered harmful in C
#313Earlier quoted context omitted.
> Tail recursion is clearer and easier to reason about than loops tail recursion is a complex and subtle expression of control flow that requires substantial background knowledge to be able to even understand, much less reason about based on code on a page for loops are immediately intuitive to anyone, even without any programming training no idea how you can come to this conclusion. just ain't so
> tail recursion is a complex and subtle expression of control flow That is simply nonsense; it's just function application, ideally without having to think about state (or as little state as possible). > for loops are immediately intuitive to anyone, for loops are immediately intuitive to anyone That's just hand-waving without some sort of psychological data. Even if it were true, it would not be relevant because yo…
programs are recipes, not proofs. "for 10 times, do this" is in almost all cases trivially easier to understand and maintain than a recursive alternative. this isn't controversial in any way
Re: GOTOphobia considered harmful in C
#314Earlier quoted context omitted.
> the idea that for loops are somehow easier than recursion is definitely not from mainstream CS I have never in my life heard a programmer say they think recursion is easier than loops.
That only shows you haven't known any programmers who had a broad exposure to the topics of their supposed craft; it doesn't speak to the actual topic itself. Recursive solutions being easier to verify is quantifiable . This is not some popularity poll. Some people are not well-versed in some techniques. Recursion is not always well supported in programming languages. In standard C if we want to use recursion, we wil…
Re: GOTOphobia considered harmful in C
#315Earlier 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. 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…
Where would once find examples of such code?
Re: GOTOphobia considered harmful in C
#316Earlier quoted context omitted.
There's nothing wrong with undefined behaviour.
Undefined behavior means the language provides no guarantees about the outcome. Whatever happens is up to the compiler, or rather the specific implementation of the compiler, and the target architecture on which the program is run. These things are not constrained by any spec or guarantee, so they are allowed to change, for any reason, to anything. These changes may be triggered by not only different execution enviro…
No, not "the language", but "the standard".
Languages like Python or Rust that don't have standards are 100 percent undefined behavior.
If you're really worried about this, then just code against x86_64 clang and not ISO C++ and forget about this non-problem forever.
Re: GOTOphobia considered harmful in C
#317Earlier quoted context omitted.
Undefined behavior means the language provides no guarantees about the outcome. Whatever happens is up to the compiler, or rather the specific implementation of the compiler, and the target architecture on which the program is run. These things are not constrained by any spec or guarantee, so they are allowed to change, for any reason, to anything. These changes may be triggered by not only different execution enviro…
> Undefined behavior means the language provides no guarantees about the outcome. No, not "the language", but "the standard". Languages like Python or Rust that don't have standards are 100 percent undefined behavior. If you're really worried about this, then just code against x86_64 clang and not ISO C++ and forget about this non-problem forever.
Re: GOTOphobia considered harmful in C
#318Earlier quoted context omitted.
> Undefined behavior means the language provides no guarantees about the outcome. No, not "the language", but "the standard". Languages like Python or Rust that don't have standards are 100 percent undefined behavior. If you're really worried about this, then just code against x86_64 clang and not ISO C++ and forget about this non-problem forever.
s/language/language as defined by the specification that also defines the concept of undefined behavior/
Re: GOTOphobia considered harmful in C
#319Earlier quoted context omitted.
s/language/language as defined by the specification that also defines the concept of undefined behavior/
Like I said, Rust and Python have no specification at all, so technically any program written in them is undefined behavior, depending on the particular interpreter/compiler binaries you use and your architecture.