Live data from Hacker News

GOTOphobia considered harmful in C

blog.joren.ga

241–250 of 319 posts

Re: GOTOphobia considered harmful in C

#241

Earlier quoted context omitted.

What bothers me about rust is the designers are people that have been bitten hard by working on browsers written in C++ with it's manual memory management and no way to enforce object lifetimes. Rusts solution to that seems like a big hammer when it comes to embedded where you usually have either stack allocated or compile time allocated objects.

If you code in that style you won't even notice the borrow-checker is there. Unless you have a bunch of shared global state, the the overhead of arc will seem silly on your single core uc.

That kind of style is often correlated with a lot of shared global state, even in relatively high level software like database engines. Most software avoids shared global state by delegating that implementation to the operating system, which often comes at the cost of performance.

Re: GOTOphobia considered harmful in C

#242

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.

It's not GOTOphobia. It's people blindly doing what others are telling them to do (or not to do) without the ability to critically think about what they're being told.

Lots of people just follow whatever anyone, who they perceive as authority, says. Critical thinking isn't a common trait.

Re: GOTOphobia considered harmful in C

#244
post #97
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…

Where would once find examples of such code?

Re: GOTOphobia considered harmful in C

#245
post #97
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…

I learned coding in the 90s and I've seen that kind of code. While BASIC itself already advanced to the point where structured conditionals and loops were available pretty much everywhere, plenty of code that was written earlier was still around.

Re: GOTOphobia considered harmful in C

#246

Earlier quoted context omitted.

> 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 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 will have to write multiple standalone functions that have their own scopes, whereas if we put together several loops, we can have those all in the same scope, with convenient access to common local variables. That could make a decisive difference. Not all languages have tail calls; what looks like tail recursion can "blow the stack".

When I say that it's "easier" I don't mean that anyone of any skill level and background can more easily design and implement a recursive solution for any problem, and in any language. Rather, that when the recursive solution is discovered, it is easier to convince oneself that it is correct: that it's handling all the cases and terminates, with the correct value.

Re: GOTOphobia considered harmful in C

#247
post #53

Earlier quoted context omitted.

That error is not due to goto, it was just a goto which was errously executed because of badly formatted code. (It looked like the statement was inside an if-block due to the indent.) Pyhon would have prevented this bug, but so would a formatter. Rust also requires braces for if-blocks to prevent this kind of error.

"The problem isn't C, it's that they weren't using C properly..."

It is not a problem specific to C. Any language where indents are independt of semantics is prone to this kind of bug.

Re: GOTOphobia considered harmful in C

#248

Earlier quoted context omitted.

> The first program listing is on page 24 of the PDF. Try to follow the logic of the program. Why does line 400 go to 280? What paths can lead to line 400? Who knows! Without looking at the post-program material, this isn't exactly a difficult question to answer. Line 400 is preceded by some print statements: 370 PRINT "PRESS 'E' TO END, SPACE TO CONTINUE" 380 GET R$:IF R$="" THEN [goto] 380 390 IF R$="E" THEN [goto]…

Now imagine you have got a typo: 400 L=0:GOTO 290 This would be almost impossible to debug.

That would correspond to the following C:

    /* 280 */
    do_something();
    for (;;) {
      /* 290 */
      /* display chart in blocks of 18 lines */
      /* 400 */
      L = 0;
    }
when the correct code is this:

    for (;;) {
      /* 280 */
      do_something();
      /* 290 */
      /* display chart in blocks of 18 lines */
      /* 400 */
      L = 0;
    }
The bug is that the call to do_something() precedes the outer loop when it should be inside the loop.

Is that easier to debug in C than it is in the BASIC program? What's the difference?

Re: GOTOphobia considered harmful in C

#249
post #20

If you’ve ever actually written more than toy C, you’ll know gotos are essential for resource cleanup and error handling. Even the famous goto fail was not a goto error, it was a block error (named because a cleanup statement `goto fail;` always executed because of a brace-less if). goto can be abused like any other language construct, but it’s uniquely useful and makes code more simple and easy to reason about when…

Not really, I have deployed plenty of C code into production and never used gotos, other than special flavoured gotos like UNIX signals.

My problems have always been in how memory corruption friendly C happens to be, nothing to do with how to use structured programming practices for resource cleanup.

Re: GOTOphobia considered harmful in C

#250
post #132

Earlier quoted context omitted.

of course nobody should be writing C any more, for exactly the reason you're demonstrating in this comment

What language do you think Linux and Arduino should be programmed in?

Arduino uses C++, thankfully.
Post reply on HN