[go-nuts] Why have goto statements?

[Cody Scott]

Goto statements have been dead for years, if Go is all about the new
why bring them back and keep them around for many years.

goto statements have been frowned upon and are not taught in schools
anymore.


--
Subscription settings: http://groups.google.com/group/golang-nuts/subscribe?hl=en

[Devon H. O'Dell]

2010/4/25 Cody Scott <cody.j....@gmail.com>:

> Goto statements have been dead for years, if Go is all about the new
> why bring them back and keep them around for many years.
>
> goto statements have been frowned upon and are not taught in schools
> anymore.

False.

--dho

[jimmy frasche]

On Sun, Apr 25, 2010 at 1:09 PM, Cody Scott <cody.j....@gmail.com> wrote:
> Goto statements have been dead for years, if Go is all about the new
> why bring them back and keep them around for many years.
>
> goto statements have been frowned upon and are not taught in schools
> anymore.

They on rare occasions can make code clearer, if used judiciously.
They're a tool. They can be misused as easily as a hammer can be.
Don't like 'em, don't use 'em.

[chris dollin]

On 25 April 2010 21:09, Cody Scott <cody.j....@gmail.com> wrote:

Goto statements have been dead for years, if Go is all about the new
why bring them back and keep them around for many years.

goto statements have been frowned upon and are not taught in schools
anymore.

GOTO statements are dead useful in machine-generated code.

(Being "frowned upon" and "not taught in schools anymore" are
not helpful arguments, either.)

The thing about language constructs that you don't expect
to need very often is that they're just as present in the language
as things you use every hour. That doesn't mean you have to
use them, and it doesn't stop code reviewers frowning on them
for the right reasons.

I wouldn't expect to ever write a goto in Go code, but I'd expect
to write code that generated gotos in generated Go code. The
controls structures in my pet programming language wouldn't
always map directly into Go control structures without a deal
of bending, at which point generating GOTOs is the clearer
option ...

Chris

--
Chris "allusive" Dollin

[James Fisher]

Go has goto?  Sweet.  (And, how appropriate. :)

[Peter Bourgon]

On Sun, Apr 25, 2010 at 10:09 PM, Cody Scott <cody.j....@gmail.com> wrote:
> Goto statements have been dead for years, if Go is all about the new
> why bring them back and keep them around for many years.

I wouldn't say goto's have been "dead for years" -- they're useful in
rare circumstances, particularly for error handling, and especially in
a systems language that lacks exceptions. But, I agree they are often
abused by C programmers, and I would say abused by Go source as well:

$ find src/pkg -name *.go -print | xargs grep "goto" | wc -l
165

I'm sure reasonable people will disagree, but I find that statistic (1
goto for every ~1000 lines of code) an order of magnitude too high. I
guess it depends on if you look at goto as "just another way of
creating a jmp" or "absolute worst-case crutch to be avoided if at all
possible." Firmly in the latter camp, myself.

[andrey mirtchovski]

>  $ find src/pkg -name *.go -print | xargs grep "goto" | wc -l
>      165
>

100% of those are used only in one particular style of error handling.
that style has been in use (in C) for at least as long as I've known
plan9's sources. it's just a programming style.

(in Plan9's sources there's one goto for every 200 or so lines of
code, used in pretty much the same manner).

[Cody Scott]

On Apr 25, 4:23 pm, Peter Bourgon <peterbour...@gmail.com> wrote:

> On Sun, Apr 25, 2010 at 10:09 PM, Cody Scott <cody.j.b.sc...@gmail.com> wrote:
> > Goto statements have been dead for years, if Go is all about the new
> > why bring them back and keep them around for many years.
>
> I wouldn't say goto's have been "dead for years" -- they're useful in
> rare circumstances, particularly for error handling, and especially in
> a systems language that lacks exceptions.

Wouldn't it be better to handle those errors properly in Go rather
than use goto statements.

[mg]

On Apr 25, 10:09 pm, Cody Scott <cody.j.b.sc...@gmail.com> wrote:
> Goto statements have been dead for years

In a way they just have a different name (breaking from a labelled
block in JavaScript is not so much different, I guess). C# uses goto
for fallthrough on switch statements.

[Giles Lean]

Cody Scott <cody.j....@gmail.com> wrote:

> On Apr 25, 4:23=A0pm, Peter Bourgon <peterbour...@gmail.com> wrote:
> > On Sun, Apr 25, 2010 at 10:09 PM, Cody Scott <cody.j.b.sc...@gmail.com> w=

> rote:
> > > Goto statements have been dead for years, if Go is all about the new
> > > why bring them back and keep them around for many years.
> >
> > I wouldn't say goto's have been "dead for years" -- they're useful in
> > rare circumstances, particularly for error handling, and especially in
> > a systems language that lacks exceptions.
>
> Wouldn't it be better to handle those errors properly in Go rather
> than use goto statements.

Suggested syntax for "properly"?

Without a pre-processor (thus no C style macros) and not wanting to
duplicate identical error handling code in many places, what's wrong
with the gotos on the exit path? It's a common idiom in C, and not
just in Plan9.

Other than similar error cases I've only used goto once that I recall in
go, and that was because doing so allowed me to exactly match in the
code the way the specification for that particular code was written.
All jumps were forward, and it was essentially a state machine. I even
added a comment indicating why I'd chosen that implementation style.

Had I been producing the work for an undergraduate assignment, I would,
of course, have used one or many state variables instead. Back in the
real world the test is comprehensibility and maintainability. By itself,
goto != sphagetti.

Regards,

Giles

[Sonia Keys]

+1 for goto. I like having it around.

[Rob 'Commander' Pike]

On Apr 25, 2010, at 10:23 PM, Sonia Keys wrote:

> +1 for goto. I like having it around.

It's really handy if you need to go to somewhere.

-rob

[Norman Yarvin]

On Mon, Apr 26, 2010 at 08:22:41AM +1000, Giles Lean wrote:

>Cody Scott <cody.j....@gmail.com> wrote:
>
>> On Apr 25, 4:23=A0pm, Peter Bourgon <peterbour...@gmail.com> wrote:
>> > On Sun, Apr 25, 2010 at 10:09 PM, Cody Scott <cody.j.b.sc...@gmail.com> w=
>> rote:
>> > > Goto statements have been dead for years, if Go is all about the new
>> > > why bring them back and keep them around for many years.
>> >
>> > I wouldn't say goto's have been "dead for years" -- they're useful in
>> > rare circumstances, particularly for error handling, and especially in
>> > a systems language that lacks exceptions.
>>
>> Wouldn't it be better to handle those errors properly in Go rather
>> than use goto statements.
>
>Suggested syntax for "properly"?
>
>Without a pre-processor (thus no C style macros) and not wanting to
>duplicate identical error handling code in many places, what's wrong
>with the gotos on the exit path? It's a common idiom in C, and not
>just in Plan9.

Not to join in any bigoted goto-bashing, but a lot of those cases could
also be handled with defer statements. That is, if something needs to be
cleaned up before the routine exits, you can push a routine on the defer
stack to do that; then, instead of "goto cleanup", you just return.


--
Norman Yarvin http://yarchive.net

[Giles Lean]

Norman Yarvin <yar...@yarchive.net> wrote:

> Not to join in any bigoted goto-bashing, but a lot of those
> cases could also be handled with defer statements. That is,
> if something needs to be cleaned up before the routine
> exits, you can push a routine on the defer stack to do that;
> then, instead of "goto cleanup", you just return.

Indeed; I have a REVISIT against my 'goto error_return' code
for that reason. The additional complexity of having to set
an error variable (I want cleanup only on errors, not on
successful completion) makes it unclear that defer will be
cleaner, but I need to implement the code both ways and
compare.

Certainly defer() is more politically correct than goto, and
defending gotos in code reviews is typically frustrating for
people on both sides (i.e. those that insist goto == bad and
those of us who are perhaps more flexible).

Giles

[Kevin Ballard]

I agree. We should replace them with COMEFROM instead.

-Kevin Ballard

--
Kevin Ballard
http://kevin.sb.org
kbal...@gmail.com

[Jessta]

On Tue, Apr 27, 2010 at 5:35 AM, Kevin Ballard <kbal...@gmail.com> wrote:
> I agree. We should replace them with COMEFROM instead.
>
> -Kevin Ballard

COMEFROM is awesome. You can't do aspect orientated programming without it.


- jessta
--
=====================
http://jessta.id.au

[ceving]

On 26 Apr., 00:22, Giles Lean <giles.l...@pobox.com> wrote:
> > Wouldn't it be better to handle those errors properly in Go rather
> > than use goto statements.
>
> Suggested syntax for "properly"?

There are pretty old and pretty elegant solutions to handle errors
without gotos and exceptions:

http://en.wikipedia.org/wiki/Call-with-current-continuation

[Ian Lance Taylor]

(I used to do a lot of Scheme programming.)

Call-with-current-continuation is a very powerful and elegant
construct, but it can make your program even harder to understand than
using a goto statement. A maintainable program can only use it in
mechanical patterns which are well understood. Also, there is no way
to implement it efficiently in the general case.

Ian

[adam_smith]

I agree with Linus Torvalds here. goto is a tool. Used right it is
nothing wrong with it. For most part of my +12 years as a C++
developer I have swallowed all the lame rules of thumbs about always
use accessor, never use goto's, objects are good, imperative
programming bad bla bla bla. And in the last years it has downed upon
me how it hasn't really gained me anything. I worked with software
following all kinds of "rules" like this, were most developers
couldn't really articulate why these rules are good except that, this
is the right way to do it. Some of Linus Torvalds provocative
arguments provoked me to look at the git and linux kernel source code.
Despite being written in C, by loads of people I was surprised by how
clean and clearly written it was. Functions were short and quite easy
to follow. Never very deep nesting etc.

That is what is wrong with the software industry I think. People
follow this silly rules like "goto is bad" thinking it is going to
solve all problems, while they have no clue about how the properly
modularize their programs. Sorry if this is a rant. But I come across
so much crap code every week that I have to try to make sense of. If
only people had cared about producing quality code instead of adhering
to a long checklist of rules that make no sense out of context.

I think it is great that the Go team don't listen to the people who
want Go to follow all kinds of silly rules. It is refreshing with such
an minimalistic and such a practical programming language. Only wish I
had read Rob Pike and Kernighan's ideas about software development
before I wasted countless years on chasing OOP nirvana in C++.

On Apr 25, 10:09 pm, Cody Scott <cody.j.b.sc...@gmail.com> wrote:

[Jo Chasinga]

Frowned upon? Like JavaScript was frowned upon?

I think powerful tools often give users the power to decide. That's freedom of choice.

IMHO `goto` can be useful if labels are placed forward in the code.

[Kostarev Ilya]

Сuriously, wikipedia consider ‘goto’ as obligatory co-statement for ‘if’ in imperative language to be Turing-complete. 

-- 
Kostarev Ilya

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

On Sat, Oct 4, 2014 at 10:20 PM, Jo Chasinga <jo.ch...@gmail.com> wrote:
> Frowned upon? Like JavaScript was frowned upon?
>
> I think powerful tools often give users the power to decide. That's freedom
> of choice.
> IMHO `goto` can be useful if labels are placed forward in the code.

Just checking: Do you know that you are replying to a thread from over
four years ago?

Ian

> On Sunday, April 25, 2010 4:09:22 PM UTC-4, Cody Scott wrote:
>>
>> Goto statements have been dead for years, if Go is all about the new
>> why bring them back and keep them around for many years.
>>
>> goto statements have been frowned upon and are not taught in schools
>> anymore.
>>
>>
>> --
>> Subscription settings:
>> http://groups.google.com/group/golang-nuts/subscribe?hl=en
>

[Panisuan Chasinga]

Hi Ian,

Thanks for the heads up. Just noticed that. Well, got so hooked up with Go for a few weeks so…
Still I think the topic was still relevant (since the feature discussed is still here) so I jumped in.

p.s. For some reasons coding in Go for me seems way faster even than Python. Perhaps something to do with syntax. Lovin' it.

[Michael Jones]

You'll love _goto_ as well when you need to write a program to generate programs from logic diagrams, state machines, and other realms. You will think, "Those Go authors sure were lucky to have just the facility for expressing the output of YACC and LEX." :-)

On Oct 5, 2014 12:31 PM, "Panisuan Chasinga" <jo.ch...@gmail.com> wrote:

Hi Ian,

Thanks for the heads up. Just noticed that. Well, got so hooked up with Go for a few weeks so...

[andrewc...@gmail.com]

I think the goto hate in the original post is basically a cargo cult of people not being taught properly. The origins of the problem are when goto was literally used for everything. Now professors and businesses who are addicted to java just repeat it mindlessly without understanding the original reasons.

[Panisuan Chasinga]

Agreed. I think some people just merely don't understand. I do not understand a lot of things, but I usually just ask around and not referencing something like "it's not taught anymore" and "frowned upon". I mean it just sound so "Facebooky." :)

[⚛]

In Tul-FX, I am testing the idea of having no control flow statements other than gotos. It works reasonably well so far. The source code compression resulting from having while-loops, for-loops, break and continue statements in a language isn't that high.

In my opinion, an unsafe programming language should definitely provide goto statements. In a safe programming language goto statements introduce issues that need to be handled by the compiler and by the language specification, such as jumping from in outer scope into an inner scope, so having gotos in a safe programming language is questionable, but in my opinion even safe imperative programming languages (Java, etc) should provide goto statements.