[G0rman]

GOTOs are considered "evil", but does that mean they should be forbidden knowledge? Is it important to learn about GOTOs in order to understand why they are bad?


Evil or not, they do exist in a lot of code. When I worked as a VB maintenance coder (yup, 10 year old VB code - I don't know why anyone was writting VB in 2000 but I digress) I saw a lot of GOTOs. I can't imagine that not knowing about GOTOs would have made my life easier. Besides that we didn't really have the funds to fix hundreds of thousands of lines of legacy code just to remove GOTOs.

OO and patterns are much more dangerous than GOTOs, and we seem happy to teach them to first year students.

[baavgai]

There is quite a difference between knowing and teaching. Teaching by negative example is questionable; see this, it's crap, see this, it's good, now what was crap again?

There a many elements of any programming language that are best avoided, even if they are found in legacy code perpetuated because of that. Far better to note them as the archaic practices that have been set aside than dredge them up again. Let the dead rest in peace.

G0rman, on 11 October 2012 - 09:43 AM, said:

OO and patterns are much more dangerous than GOTOs, and we seem happy to teach them to first year students.

Bullshit. Define dangerous.

[G0rman]

baavgai, on 11 October 2012 - 10:00 PM, said:

There is quite a difference between knowing and teaching. Teaching by negative example is questionable; see this, it's crap, see this, it's good, now what was crap again?

Well if we are talking about a university, then the premise seems to be that to know something, you have to have been taught it
I don't suggest teaching by negative example, but certainly "this is a GOTO, this is what it does, this is how it has been used historically, this is what it is good for / bad for" is fine.

baavgai, on 11 October 2012 - 10:00 PM, said:

There a many elements of any programming language that are best avoided, even if they are found in legacy code perpetuated because of that. Far better to note them as the archaic practices that have been set aside than dredge them up again. Let the dead rest in peace.

That may be so, but if your job may require you to know them (and I don't think that it is that unreasonable to expect people to understand GOTOs) then why wouldn't you be taught it?

The university I study at covers ADA, FORTRAN, COBOL, and many other legacy languages - however when it comes to Java you get a stern look and "this language doesn't have GOTOs".

baavgai, on 11 October 2012 - 10:00 PM, said:

G0rman, on 11 October 2012 - 09:43 AM, said:

OO and patterns are much more dangerous than GOTOs, and we seem happy to teach them to first year students.

Bullshit. Define dangerous.

If you teach someone OO, they will use OO for everything - you will have a 100 classes where 10 would have been necessary. This is as dangerous as misusing GOTOs, ask me to maintain code with 10x the number of classes it should have, or spaghetti code and I will have to think carefully before making that choice.
Teach someone patterns and everything will have a builder and follow MVC design - once again bloating code and making it hard to maintain.

That's basically what I mean by dangerous. Same as GOTO's - they can make your code unmaintainable and if you aren't attentive they can cause all sorts of problems.

[jon.kiparsky]

G0rman, on 11 October 2012 - 08:43 AM, said:

GOTOs are considered "evil", but does that mean they should be forbidden knowledge? Is it important to learn about GOTOs in order to understand why they are bad?

The problems with GOTOs are mostly long-term ones, problems that come up in medium and large scale applications and in maintenance over extended periods. Therefore, it's hard to come up with good examples of their badness that are suitable for classroom use, but that doesn't mean that they don't cause problems.

One useful classroom exercise might be to generate or even buy some legacy code like you describe and introduce a few bugs. Let the students try to debug it. Then perform the same exercise with well-structured code - if our claims about goto are correct, the latter should be much easier.

We could come up with a few more such examples, but one should really be amenable to reasonable arguments about this sort of thing.

Quote

Evil or not, they do exist in a lot of code. When I worked as a VB maintenance coder (yup, 10 year old VB code - I don't know why anyone was writting VB in 2000 but I digress) I saw a lot of GOTOs. I can't imagine that not knowing about GOTOs would have made my life easier.

I'm not sure how much you need to know about them. You see a GOTO, you go to that label.
Next?

Quote

Besides that we didn't really have the funds to fix hundreds of thousands of lines of legacy code just to remove GOTOs.

I think it's generally felt that best practice in a case like this is to refactor the offending code when making other changes (bug fixes, new features). Since you're changing the code in any case, and introducing risk, you might as well try to reduce future risk at the same time.
You wouldn't do a major refactor just to do it - if the code is stable, there's no point in stirring it up.

This post has been edited by jon.kiparsky: 11 October 2012 - 07:13 AM

[jon.kiparsky]

G0rman, on 11 October 2012 - 09:11 AM, said:

If you teach someone OO, they will use OO for everything - you will have a 100 classes where 10 would have been necessary. This is as dangerous as misusing GOTOs, ask me to maintain code with 10x the number of classes it should have, or spaghetti code and I will have to think carefully before making that choice.
Teach someone patterns and everything will have a builder and follow MVC design - once again bloating code and making it hard to maintain.

That's basically what I mean by dangerous. Same as GOTO's - they can make your code unmaintainable and if you aren't attentive they can cause all sorts of problems.

This doesn't make a lot of sense to me. To be charitable, this sounds like bad engineering, not a bad paradigm. Someone who uses a bad architecture or creates a lot of classes is simply not good at design. Someone who makes heavy use of unrestricted jumps instead of higher-level structures creates code which is less predictable and therefore more difficult to maintain - also, not good design.
The difference is that object-oriented design makes it easier to do good design - not harder. GOTO makes it harder to do good design, not easier.

[G0rman]

I realize that everythign I say about university is pretty much my own experience, so be aware that perhaps our course is just not well structured or missing some parts that others cover. YMMV.

jon.kiparsky, on 11 October 2012 - 10:12 PM, said:

One useful classroom exercise might be to generate or even buy some legacy code like you describe and introduce a few bugs. Let the students try to debug it. Then perform the same exercise with well-structured code - if our claims about goto are correct, the latter should be much easier.

I like this idea, for 2 reasons.

Firstly, not enough debugging other people's code in this uni
Secondly, not enough reading other people's code in this uni

Oh, and yeah, learning about GOTOs.

jon.kiparsky, on 11 October 2012 - 10:12 PM, said:

I'm not sure how much you need to know about them. You see a GOTO, you go to that label.
Next?

More like being familiar with them. Especially the unusual ones in languages like FORTRAN.

jon.kiparsky, on 11 October 2012 - 10:12 PM, said:

You wouldn't do a major refactor just to do it - if the code is stable, there's no point in stirring it up.

Indeed. Which is why I might be so apathetic towards GOTOs. If the code works I'm not going to go out of my way to break it just to fix it. I do refactor what I can within reason, but not on a large scale - never know when a trap GOTO could be lurking.

Though I'm not about to go coding in GOTOs just because "it works".

jon.kiparsky, on 11 October 2012 - 10:19 PM, said:

This doesn't make a lot of sense to me. To be charitable, this sounds like bad engineering, not a bad paradigm. Someone who uses a bad architecture or creates a lot of classes is simply not good at design. Someone who makes heavy use of unrestricted jumps instead of higher-level structures creates code which is less predictable and therefore more difficult to maintain - also, not good design.
The difference is that object-oriented design makes it easier to do good design - not harder. GOTO makes it harder to do good design, not easier.

You can create just as big a mess with OO and patterns as you can with GOTOs. I guess it comes down to "is there any legitimate use for GOTOs".

What do you think of

k=49;
int temp;
for(int i=0;i<10;i++) {
	for(int j=0;j<10;j++) {
		temp=i*j;
		if(temp=k) break;
	}
	if(temp=k) break;
}
if(temp!=k) printf(“didn’t find %d!”,k);

VS

k=49;
for(int i=0;i<10;i++) {
	for(int j=0;j<10;j++) {
		if(i*j=k) goto end;
	}
}
printf(“didn’t find %d!”,k);
end: ;

Can you honestly say the former is "better code" than the latter? Ignoring that GOTOs are intrinsically evil of course.


EDIT: Rewritten for those who believe break is intrinsically evil too

k=49;
int temp, i=0, j=0;
while(i<10&&temp!=k) {
	while(j<10&&temp!=k) {
		temp=i*j;
		j++;
	}
	i++;
}
if(temp!=k) {
	printf(“didn’t find %d!”,k);
} else {
	j--;
}

This post has been edited by G0rman: 11 October 2012 - 07:34 AM

[JackOfAllTrades]

Or,

bool found = false;
k=49;
for(int i=0; !found && i<10; i++) {
   for(int j=0; !found && j<10; j++) {
      found = (i * j == k);
   }
}
if (!found)
   printf(“didn’t find %d!”,k);

[G0rman]

JackOfAllTrades, on 11 October 2012 - 10:36 PM, said:

Or,

bool found = false;
k=49;
for(int i=0; !found && i<10; i++) {
   for(int j=0; !found && j<10; j++) {
      found = (i * j == k);
   }
}
if (!found)
   printf(“didn’t find %d!”,k);

Good one!

So do you prefer this?


I guess it's ok to put other conditions in to a for loop's conditions.

This post has been edited by G0rman: 11 October 2012 - 07:41 AM

[jon.kiparsky]

If I really wanted to use a nested loop for something like that, I'd use a labeled break, if those exist in VB. (funny, I just commented on fromTheSprawl's blog to the effect that I only ever use labeled blocks in examples here on DIC ) The break syntax is better in my view because it's more specific: you know exactly where you can go with it, you can go to the endpoint of an enclosing loop, period. That means that the maintaining programmer can easily find the endpoint of the jump, and more important they know what sort of a jump is meant. It also means that it's impossible to create a side-track loop. Breaks always indicate a return to the control flow, they never branch from it. This also simplifies maintenance.


So yes, I do think the break is a better syntax than the GOTO.

EDIT: I also like JackOfAllTrades's solution. It skates close to the edge of clever, but it stays on this side of the line.

This post has been edited by jon.kiparsky: 11 October 2012 - 07:47 AM

[AdamSpeight2008]

If you're going teach GoTo, then start with the idea of labeling (or signposting ) a line of code. A line of code you can then jump the execution flow to or GoTo. Then set them the task of implementing the higher level looping abstractions. Only using If Statements and GoTo.
For Loop
While Loop
Do Until
Select Case

Spoiler

               int loopValue  = _InitalValue_
_StartOfLoop_: If  loopValue  > _Endvalue_  Then GoTo _ExitTheLoop_
               {_loop_body}
               loopValue += _Stepping_Value
               GoTo _StartOfLoop_
 _RestOfCode_: 

Note: only describes ascending for-loop.

Since my view is If and Goto are the basic building block from which the other built on. If you've got some more adventurous coder, then set the task of doing the same task but only to implement loops using recursion. Which is touching on Functional approach.

Then explain that some programming do have GoTo, it considered bad practice to use them when the higher level abstractions are available.

Edit: Exit For only exits that level of For-Loop, if you have nested For-Loops you then have to repeat yourself at the next level

For z = 0 To 99
  For y = 0 To 99 
    For x = 0 To 99
      If data(z,y,x) = False Then
        result = New Position(x,y,z)
        GoTo exit_nesting
      End If
    Next x
  Next y
Next z
exit_nesting: 

This post has been edited by AdamSpeight2008: 11 October 2012 - 07:58 AM

[baavgai]

G0rman, on 11 October 2012 - 10:11 AM, said:

Well if we are talking about a university, then the premise seems to be that to know something, you have to have been taught it

The student is free to amend their education as they will. There are many elements of any given subject that aren't covered in lectures or required reading. If you want to know what a GOTO is, you can certainly track it down. It's not a particularly challenging concept. However, working it into the curriculum seems a criminally poor use of resources.

G0rman, on 11 October 2012 - 10:11 AM, said:

I don't suggest teaching by negative example, but certainly "this is a GOTO, this is what it does, this is how it has been used historically, this is what it is good for / bad for" is fine.

You're missing the point; it's not "good for" anything. There are no modern languages were you must use GOTO. Certainly not VB, even dead VB. You need a GOTO, or JUMP, in assembler; teach it there.

[quote name='baavgai' date='11 October 2012 - 10:00 PM' timestamp='1349964021' post='1720896']

G0rman, on 11 October 2012 - 09:43 AM, said:

Not if you teach them correctly. Sure, you can write terrible OO code. You can write terrible code in any paradigm. And all languages have elements that should be used sparingly or not at all. Don't use globals, unless you must. Parallel arrays are poor design, but sometimes make sense. GOTOs... well, they are simply never required and introduce a plethora of potential problems, so why

Not if you teach them correctly. Sure, you can write terrible OO code. You can write terrible code in any paradigm. And all languages have elements that should be used sparingly or not at all. Don't use globals, unless you must. Parallel arrays are poor design, but sometimes make sense. GOTOs... well, they are simply never required and introduce a plethora of potential problems, so why bother?

[G0rman]

jon.kiparsky, on 11 October 2012 - 10:44 PM, said:

If I really wanted to use a nested loop for something like that, I'd use a labeled break, if those exist in VB. (funny, I just commented on fromTheSprawl's blog to the effect that I only ever use labeled blocks in examples here on DIC ) The break syntax is better in my view because it's more specific: you know exactly where you can go with it, you can go to the endpoint of an enclosing loop, period. That means that the maintaining programmer can easily find the endpoint of the jump, and more important they know what sort of a jump is meant. It also means that it's impossible to create a side-track loop. Breaks always indicate a return to the control flow, they never branch from it. This also simplifies maintenance.


So yes, I do think the break is a better syntax than the GOTO.

EDIT: I also like [@JackOfAllTrades]'s solution. It skates close to the edge of clever, but it stays on this side of the line.

Personally I think considering only readability the GOTO is best. The breaks would be second best because they are explicit - as you said - but I have to make a redundant break call.

[@JackOfAllTrades]'s is great but if you slipped one of those in casually, I can see some people glancing over it "oh a for loop, got it" and not even realizing the second condition. The simple solution is don't skim read code, but it's going to happen

Your point about the structure of break and the inability to create a side-track loop is a good one, and I'll bring that up later (don't want to clog the thread with too many points all at once, else everything get's discussed just a little instead of getting a bit of depth).

[jon.kiparsky]

G0rman, on 11 October 2012 - 09:51 AM, said:

[@JackOfAllTrades]'s is great but if you slipped one of those in casually, I can see some people glancing over it "oh a for loop, got it" and not even realizing the second condition. The simple solution is don't skim read code, but it's going to happen

That's exactly what I meant by "skating close to the edge of clever". Clever is bad, because it assumes the person reading the code is clever enough to figure out what you meant, and (as you say) that they're not in a hurry or otherwise distracted (say, by a manager yelling at them to fix it NOW NOW NOW)

[baavgai]

For Jack's example:

bool hasK(int k) {
	for(int i=0; i<10; i++) {
		for(int j=0; j<10; j++) {
			if (i * j == k) { return true; }
		}
	}
	return false;
}

int k=49;
if (!hasK(k)) { printf(“didn’t find %d!”,k); }

[G0rman]

AdamSpeight2008, on 11 October 2012 - 10:50 PM, said:

Then explain that some programming do have GoTo, it considered bad practice to use them when the higher level abstractions are available.

I like what you said, teaching programming from the ground up - after all, deep down everything is just jumps!

Control structures are very good at what they are made to do, but there's no standard way to do things that control structures aren't made for (arguably) as shown with the nested for loop examples above.

How should we deal with structures that cannot be dealt with cleanly by if,for,while,switch,sub()?

baavgai, on 11 October 2012 - 10:51 PM, said:

The student is free to amend their education as they will. There are many elements of any given subject that aren't covered in lectures or required reading. If you want to know what a GOTO is, you can certainly track it down. It's not a particularly challenging concept. However, working it into the curriculum seems a criminally poor use of resources.

As I mentioned before, YMMV, but in the curriculum here, I think we have plenty of things less important than GOTO which are being covered.

baavgai, on 11 October 2012 - 10:51 PM, said:

you're missing the point; it's not "good for" anything. There are no modern languages were you must use GOTO. Certainly not VB, even dead VB. You need a GOTO, or JUMP, in assembler; teach it there.

There are no modern languages where you "must" use for loops. I don't think that line of logic will get us anywhere...

baavgai, on 11 October 2012 - 10:00 PM, said:

GOTOs... well, they are simply never required and introduce a plethora of potential problems, so why bother?

Feel free to comment on the examples. It seems like you are just saying "but they are really bad" instead of giving reason. I've not heard of a language that doesn't have GOTOs (those I assume they do exist), and up until the late 70s there was no real opposition against them. I would say that even well into the 90s they were used thoroughly in industry. Even if you hate them, you have to touch them every now and then.

baavgai, on 11 October 2012 - 10:57 PM, said:

For Jack's example:

bool hasK(int k) {
	for(int i=0; i<10; i++) {
		for(int j=0; j<10; j++) {
			if (i * j == k) { return true; }
		}
	}
	return false;
}

int k=49;
if (!hasK(k)) { printf(“didn’t find %d!”,k); }

Nice work, but aren't you substituting one academic phobia for another? Multiple return statements are the fruit of the devil after all!
They are right up there with globals!