Live data from Hacker News

GOTOphobia considered harmful in C

blog.joren.ga

311–319 of 319 posts

Re: GOTOphobia considered harmful in C

#311
post #77
post #50

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…

I read the paper when it first came out. At the time I was programming in Fortran which had the three branch if-statements. As you pointed out, that was a special kind of hell. The paper rang very true. However we did all take it to the extreme and go for zero goto with quite a fervor.

Re: GOTOphobia considered harmful in C

#312
post #192

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

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 environments, but also changes to properties of a given execution environment. The behavior of a program with undefined behavior is non-deterministic, and cannot be predicted, modeled, or effectively maintained.

Re: GOTOphobia considered harmful in C

#313

Earlier 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…

the only programmers who are concerned with proofs are located in universities and are writing theses, which are statistically 0% of programmers overall

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

#314

Earlier 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…

verifiability is not an important property of a program, except in very niche circumstances

Re: GOTOphobia considered harmful in C

#315
post #97

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

A modern example of code like this would be any game coded in SmileBASIC for the 3DS.

Re: GOTOphobia considered harmful in C

#316

Earlier 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…

> 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

#317

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

s/language/language as defined by the specification that also defines the concept of undefined behavior/

Re: GOTOphobia considered harmful in C

#318

Earlier 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/

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.

Re: GOTOphobia considered harmful in C

#319

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

undefined behavior is not the absence of a spec, it's a specific condition that specs define
Post reply on HN