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

Goto (2007)

beej.us

Post reply on HN
Print view View original

171–180 of 207 posts

Re: Goto (2007)

#171

Post by westcort »

bodyfour wrote: post #99

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

What I want is a language that consists ONLY of GOTO statements. The Turing tape concept indicates that it should be possible.

Re: Goto (2007)

#172

Post by Jtsummers »

slaymaker1907 wrote: post #169
Jtsummers wrote: post #139

Earlier quoted context omitted.

It's a tradeoff. defer in Go is more like a try/finally statement in other languages, there's a guarantee that the deferred code will run even when there's a panic in the intervening code: handler = open(something); defer close(handler); // something causing a panic Should be the same as: handler = open(something); try { // something causing an exception } finally { close(handler); } This is not necessarily true of g…

There is a huge difference in semantics with defer compared to RAII since defer is called at the end of the function while RAII is scope based. It's mostly the same except for if you want to use RAII in a loop.

That's a difference based on the way Go implements defer, but not a principle of defer. A lexically scoped based defer is conceivable.

That said, it's worth noting that difference in practice since Go is, as far as I know, the only mainstream language with defer as a major and commonly used construct.

Re: Goto (2007)

#173

Post by schoen »

westcort wrote: post #171
bodyfour wrote: post #99

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

What I want is a language that consists ONLY of GOTO statements. The Turing tape concept indicates that it should be possible.

Subtract and branch if negative is more or less that:

https://en.wikipedia.org/wiki/One-instruction_set_computer#S...

Re: Goto (2007)

#174

Post by recursive »

gwbas1c wrote: post #155
recursive wrote: post #144

Earlier quoted context omitted.

That's a good solution. The next problem is that many code patterns, such as state machines, if naively converted from `goto` to `call()` will consume a lot of unnecessary stack space. This might not be a problem with a language/compiler that supports tail call optimization.

Perhaps that's true when you're writing performance-critical code. For most code, readability trumps micro-optimizations.

In plenty of environments, there's a very limited number of calls you can make before the program fails entirely. For instance, in GW-BASIC, your namesake, the limit is less than 100 calls. There are plenty of real useful production langauges where your stack will run out before 1000 frames of depth.

But on the other hand, it's quite reasonable to write a state machine which is expected to make [mb]illions of state transitions.

Crash vs not-crash is not a micro-optimization.

Re: Goto (2007)

#175

Post by N0tAThr0wAway »

Goto is like a tool in your tool shed that may only be used once a year or less. It has an extremely narrow use-case, can be dangerous is used improperly, and may require more experience and training versus using your run of the mill pipe wrench.

I always hated the platitudes that people use when talking about gotos. Yes it definitely can be dangerous, yes it's probably best to refactor a specific area of your codebase to not use them, but every once in a while, it's the right tool for the right job.

Re: Goto (2007)

#176

Post by fjfaase »

billpg wrote: post #32

My favorite use of goto is with C#'s "yield return". The compiler converts a function with a yield command into a label. To resume a function from where it left off, the compiler adds code to test an added resumption-point variable and to goto the label for each resumption point.

I have used the goto statement to implement enumerators classes in C++ using a state member and a switch statement with goto statements at the start of the method. Of course, also all local (loop) variables need to be replaced by (private) members. At each 'yield' location, you set the state variable, have a return statement, followed by a label.

It is also possible to do this in C with functions and structs. See for example: https://www.iwriteiam.nl/Ha_cmt.html

Re: Goto (2007)

#177

Post by prox »

CJefferson wrote: post #101
bodyfour wrote: post #99

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

I agree with you completely. I once made a poster (I wish I'd kept it) where I was tracing out the behaviour of a single mega function with around 50 labels in it, and gotos all over the place. I worked on a reimplementation, slowly picking apart the function into subfunctions, while loops, recursive function calls, etc. Took me about 2 weeks.

You maybe the right person to ask… Aren’t function / functioncallers a form of goto?

Re: Goto (2007)

#178

Post by throwaway09223 »

0xffff2 wrote: post #112
bodyfour wrote: post #99

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

Can you give an example of where you've used goto in C or a C-like language? Or a rough estimate of the number of times you've found goto to be the best solution? I agree with your post in principle, but in practice I can't think of a single example where I've used a goto that wasn't eventually refactored to something better that didn't have the goto. Edit: Probably the most common example (and one given early in the…

There's a good real world example of goto for progressive cleanup here: https://github.com/square/pam_krb5_ccache/blob/master/pam_kr...

Re: Goto (2007)

#179

Post by rightbyte »

Jtsummers wrote: post #172
slaymaker1907 wrote: post #169

Earlier quoted context omitted.

There is a huge difference in semantics with defer compared to RAII since defer is called at the end of the function while RAII is scope based. It's mostly the same except for if you want to use RAII in a loop.

That's a difference based on the way Go implements defer, but not a principle of defer. A lexically scoped based defer is conceivable. That said, it's worth noting that difference in practice since Go is, as far as I know, the only mainstream language with defer as a major and commonly used construct.

I guess Go's "defer" is from "rescue" in Alef (the Plan 9 language). Kinda the same guys. But "rescue" was only executed on signals.

Re: Goto (2007)

#180

Post by atq2119 »

0xTJ wrote: post #9

Blanket rules like "never use `goto`" are generally not great. A big part of the job of a software developer is knowing when to use what bits of a language. Sometimes code with `goto` is simply easier to understand. You have to be careful, but dismissing it completely is throwing out a tool.

A lot of software engineering techniques are more about managing mediocrity than fostering excellence. They go overboard with the prescriptions. This may well produce better results when you have an army of mediocre developers.

It tends to frustrate excellent developers though, so it's a tricky weapon to wield.

Of course, it also tends to frustrate those who only think they're excellent.

Post reply on HN