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

201–210 of 319 posts

Re: GOTOphobia considered harmful in C

#201

Post by kevin_thibedeau »

arp242 wrote: post #77
ufo wrote: 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've seen full spaghetti on recently written C driver code for an IC. The device contained a 24-bit processor that wouldn't have a compiler and its one-man dev team was necessarily doing all of the firmware in assembly. He basically wrote all of the C with assembly style control flow, goto-ing all over the place and zero high level statements.

Re: GOTOphobia considered harmful in C

#202

Post by sedatk »

ufo wrote: 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…

That wasn’t even Dijkstra’s title. It was Niklaus Wirth who edited the title in. I mention that in Street Coder.

Re: GOTOphobia considered harmful in C

#203

Post by j16sdiz »

thaumasiotes wrote: post #179
pavlov wrote: post #86

Earlier quoted context omitted.

This. To find an example, I did a search for “Commodore PET Basic programs”. Here’s a book from 1979 that shows what spaghetti code looks like, in my opinion: http://www.1000bit.it/support/manuali/commodore/32_BASIC_Pro... 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! And this is high-quality BASIC b…

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

Re: GOTOphobia considered harmful in C

#205

Post by Gibbon1 »

galangalalgol wrote: post #198
Gibbon1 wrote: post #191

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.

> bunch of shared global state

A good indication of embedded is having to manage shared global state.

This is very unlike a browser where you can hide all that behind OS calls.

Re: GOTOphobia considered harmful in C

#206

Post by mustache_kimono »

benj111 wrote: post #110
maldev wrote: post #73

Earlier quoted context omitted.

Yes. There's a reason pretty much every secure C coding standard dictates exact what I said, like CERT C etc. There's a reason they have weird bugs. Just because it's an impressive piece of software, doesn't mean it can't have horrible design pattern written by substandard coders. And in an open source project with as many contributors as Linux, I would say it's not hard to fathom that there's a significant number of…

or maybe its that things like a kernel reasonably need to use goto? or at least at the time it was written, there werent alternatives that were performant enough.

Either is more charitable, and both are probably closer to the truth.

FYI:

4,879 code results in illumos/illumos-gate for goto

2,587 code results in freebsd/freebsd-src for goto

It's not like any comparable project is immune? Perhaps `goto` says more about how old the code is?

Re: GOTOphobia considered harmful in C

#207

Post by emodendroket »

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…

Technically nobody stops you from writing one giant function with labels and goto, it's just not the most obvious path even to the most inexperienced programmers.

Re: GOTOphobia considered harmful in C

#208

Post by astrange »

inlined wrote: post #137
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…

I used to work at Microsoft on the windows team. There it was very common to have a “goto cleanup” for all early exits. It was clean and readable. Otoh, I once was assigned to investigate an assertion error in the bowels of IE layout code. It was hundreds of stack frames deep in a recursive function that was over a thousand lines long and had multiple gotos that went forwards or backwards. That was an absolute mess a…

Any API that returns error codes has that issue; if it just returns an int you can't just set a breakpoint on the "allocate an error" method.

Re: GOTOphobia considered harmful in C

#209

Post by anonymoushn »

fsckboy wrote: post #172
mort96 wrote: post #140

Earlier quoted context omitted.

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…

tangentially, can somebody point me to what are considered the best fizzbuzz solutions? I'm both an experienced and cs-educated coder, and I know what I would consider to be a good solution, but I have no idea what the rest of "you" are looking for. (my favored solution would be a small number of state machines running in parallel to sieve-of-eratosthenes the correct answers thus avoid innumerable divisions, but mayb…

Surely your compiler won't actually emit an integer modulus if you tell it to mod by a constant?

Re: GOTOphobia considered harmful in C

#210

Post by saagarjha »

eric__cartman wrote: post #147
saagarjha wrote: post #142

Earlier quoted context omitted.

If it was created today? I’d go for Rust and Python respectively

The ATmega 328P an Arduino Uno or Nano uses has 2KB of memory and 32KB of flash storage for the program. Having some sort of micropython interpreter there would be impossible, and even if it could be achieved, somone still has to write the low level C/ASM code to make it all work. For many embedded systems, low level languages like C or C++ (perhaps Rust for a lot of ARM micros) is the only sensible choice. If it's n…

Python is more than adequate for most of the simple scripts that people run on Arduinos. There's no reason that a lightweight interpreter or even a compiled implementation could not run on even the AVR-based Arduinos, and obviously the beefier ones are straight up 32-bit ARM so it would be trivial to stand up MicroPython on them.
Post reply on HN