I like things like on x goto, label1, label2, etc...
That's fast, cheap, simple, etc... Often the replacement for it isn't.
Re: Anti authoritarian. Yep. Me too. If we give people enough tools to do powerful things, they will also do ugly things. Render the tools down, and we get fewer ugly things, but also not the really powerful / clever things. Nature of the beast.
Potatohead,
That "on x goto..." is a fine example of structured programming and not really a dangerous goto at all. It is the equivalent of switch in C, other languages have their equivalents.
I allways had the feeling that messy things like switch, break, continue, abort and exceptions were put into otherwise neat "structured" high level languages when it was realized that for practical programming you really need a goto but that had to be avoided to keep the purist "goto police" happy.
Afterall the structures I mentioned are not logically necessay in programming.
LOL! Erco, you must've known when you started this thread. When I first read it, I thought, "I'm not gonna take the bait; I'm not gonna take the bait." I took the bait. It's hopeless.
@Heater, yeah exactly. The purist structured approach isn't practical, and neither is the minimalist one. If the latter were true, assembly would still rule. If the former were true, something like a very clean Pascal would.
How would I replace on x goto ... in SPIN? Just got to thinking about that, and maybe I'm missing something, but we just can't do it without hackery. There is CASE, but that isn't quite the same. The math relationship on goto has is cheap, where CASE is different: is it this? or is it that? Maybe it's one of these? None of the above? .... all packed into a list. Useful and powerful in it's own way.
I like being able to relate things with simple math and operators, like we do in PASM. Often, a simple relationship can yield a nice savings. Coupla shifts and a mask maybe add, and then off to whatever sub-task makes sense. Fast, cheap, robust.
One frustration for me with structured languages is I tend to evolve programs, and I know that's due to me not authoring larger programs on a regular basis. That's a skill gap I work on when I can. But... With a goto type structure I can very easily setup a framework with "blocks" of code, and it makes sense like it does in assembly land. The same can be done with structured bits, but I find the planning difficult as well as just visualizing the logic, until I've seen it start to go.
In other words, how to structure when the structure isn't really known to the programmer? And I know in advance the most likely path is to build on the basics, until that problem goes away. Personally doing that, and progressing, but... it is a general question relevant to this goto discussion I would love to hear responses to. Maybe I'm missing something, or doing it wrong.
Getting it done ugly is preferable to just not getting it done, but doing so in a elegant way...
LOL! Erco, you must've known when you started this thread. When I first read it, I thought, "I'm not gonna take the bait; I'm not gonna take the bait." I took the bait. It's hopeless.
-Phil
I took the bait in the Picaxe forum and stated my case.
Twenty nine years programming (large financial applications mostly) for large corporations (GE, Humana, Federated Dept Stores, Farm Credit Banks) gives you a certain perspective...
In other words, how to structure when the structure isn't really known to the programmer?
One piece at a time, testing each until it works. I think the most damaging legacy of the "structured programming" movement was the insistence on a "top down" approach. This just doesn't work, because it's almost impossible to determine an overall structure until you know how (or whether) the pieces are going to work and fit together. Moreover, it's almost impossible to test anything until you're finished, which is a horrible way to program. But this does not mean we should throw out the baby with the bathwater. It's still possible and desirable to assemble working pieces of code in a hierarchically-structured form without resorting to spaghetti-inducing gotos. If you need gotos, something has gone badly wrong somewhere.
Getting it done ugly is preferable to just not getting it done, but doing so in a elegant way...
But never leave it in that state, and never be afraid to rewrite a block of code from scratch once you understand how it really needs to be structured. I do this all the time, even with code that nobody else will ever see, because I know that someday I will have to come back and try to understand what I did. If the program is well-structured, it's that much easier to understand and modify. I can't remember the last time I used a goto.
All this goto talk has made me wonder what y'all think of quit and abort in Spin.
I read somewhere (I think on this forum), they weren't good programming technique. I avoided using them until I saw how Kye used them. If code can be beautiful, I think Kye's code is beautiful. It seems like he puts abort to good use. Abort traps make aborts even more useful.
I still hesitate to use them, but now I don't feel so guilty when I do decide to use an abort or a quit statement.
All this goto talk has made me wonder what y'all think of quit and abort in Spin.
I read somewhere (I think on this forum), they weren't good programming technique. I avoided using them until I saw how Kye used them. If code can be beautiful, I think Kye's code is beautiful. It seems like he puts abort to good use. Abort traps make aborts even more useful.
I still hesitate to use them, but now I don't feel so guilty when I do decide to use an abort or a quit statement.
Duane
I have no problem with ABORT or QUIT - they terminate the method or repeat loop that they are in. GOTO type commands let you jump anywhere - not really comparable...
I have no problem with ABORT or QUIT - they terminate the method or repeat loop that they are in. GOTO type commands let you jump anywhere - not really comparable...
All these negative GOTO vibes inspire my contrary nature to write a program consisting mainly of GOTO statements that does something useless, but cool. Not sure exactly what it might be, other than the logical equivalent of a useless machine:
All these negative GOTO vibes inspire my contrary nature to write a program consisting mainly of GOTO statements that does something useless, but cool. Not sure exactly what it might be, other than the logical equivalent of a useless machine:
I carried a pager for many years to support production mainframe systems and probably got beeped thousands of times during my career.
Many program crashes were caused by "spaghetti code".
One clever programmer put a display message in his program that said something like:
"This error message will never display because the condition tests will prevent this code from ever executing".
Guess what message I was reading at 3:00 a.m. .........
All these negative GOTO vibes inspire my contrary nature to write a program consisting mainly of GOTO statements that does something useless, but cool.
The three escape methods you cite are infinitely better than using a GOTO. Look at it from the standpoint of the compiler writer. If a GOTO out of the scope of a loop is encountered, what to do with the control stack? Keep it intact, or pop the loop environment completely? What if, later, a GOTO back into the loop is encountered? See what I mean? GOTOs and these higher-level constructs simply do not mix.
I thought this whole debate was played out enough in the Communications of the ACM and several books years and years ago. Phil is absolutely right. Unrestricted GOTOs, like typeless pointers, are a mess to deal with when mixed with high-level control and data structures because they have the potential for breaking all the rules, even if they don't. The compiler (or the reader of the code) has no way to tell for sure.
When this whole original debate was raging, I took on a challenge from a colleague to write an operating system for the IBM 360 without any GOTOs in PL360, a high level assembly language with only limited GOTOs anyway. There were no GOTOs and only one place in the thousands of lines of code where the program counter could be forced to an arbitrary value ... in the task scheduler where a return could be made to a higher priority task than the one that called the scheduler.
The point is that GOTOs are not necessary. They can make a program harder to understand and harder to debug. They make it harder to optimize. You can write well-structured and reliable code using GOTOs, but it's harder to teach good programming style with GOTOs. Probably the one situation where a GOTO-like control structure is particularly helpful is the abort where control has to be forced to somewhere higher in the program's flow of control. Most GOTO-less languages (like Spin) have some kind of abort mechanism.
So how do we account for the nearly 93000 gotos in the Linux kernel sources? I'm sure Linus has thought good and hard about this. Can't find a link to his justification of this use of gotos just now.
My code will continue to boldly goto where no code has goneto before:)
Torvalds: "No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue."
Apparently celebrity breeds contempt for authority. If GOTO were an illegal drug, Linus might well be the Lindsey Lohan of programming.
Perhaps it's celebrity but I suspect it's the Finnish character. Having been here a while I notice they don't have so much of the English style reserve and will say what they want rather directly at times.
Anyway there is also the famous argument Linus had with an accademic about the error or not of building a monolithic kernel rather than a micro kernel. I belive that occurred before Linus was so famous.
For what it's worth, a well-thought-out GOTO can be a genuine code saver and very, very logical choice. I'm always looking for the most elegant, lowest line count programming code I can write, and I find that for invalid user inputs, for example, a few lines of code that informs the user, resets the flags and sends them back to the start with a GOTO works perfectly. It only sends them back to the start of the last menu they entered (about 12 lines up) and takes less lines and makes more sense than a subroutine. But that said - I use very very few GOTOs otherwise. My latest project occupies 5 slots to about 75% capacity each (a fuel management and tracking system) - but it has only 4 GOTOs in all that code, and all four are for weeding out bad user input. So they get my conditional approval - like that's worth anything! :-)
Of course, I have been programming in one flavor or another of BASIC since the 1970s...
1. Most members in this forum most likely have never been nor ever will be
employed as professional programmers (no offense intended)
2. It is unlikely that their code will be modified or supported by multiple
programmers (and therefore maintainability issues are moot)
3. Their code is not "mission critical" or likely to create injury or death
(let's hope)
4. Some people tend to ignore facts and proven standards under any
circumstance (if the shoe fits, wear it)
To which I have to respond:
1. It makes no odds if you are professional or not. In other "hobby"
activities like writing, poetry, music, painting, model boat building or
whatever quite often the "hobbyist" is striving for perfection. Often they can
reach a standard that surpasses any commercial equivalent you can buy. Perhaps
the word amateur is better. Why should amateur coders be any less demanding of
themselves?
2. True. Unless they put it out on the WEB as open source then who knows what
might happen (See Linux kernel as a supreme example). Even if you are the only
one to be working on your code maintainability is an issue. I have a bunch of
projects that may get looked at very infrequently. If I have left myself an
unfathomable tangled mess then it's going to be a pain to get back into them
after a while.
3. Depends what you mean by "mission". If that christmas light sequencer does
not work when you are proudly showing it off to the family that's a serious
mission failure:)
4. True.
Knock yourself out! Type GOTO statements until your fingers cramp!
1. It makes no odds if you are professional or not. In other "hobby"
activities like writing, poetry, music, painting, model boat building or
whatever quite often the "hobbyist" is striving for perfection. Often they can
reach a standard that surpasses any commercial equivalent you can buy. Perhaps
the word amateur is better. Why should amateur coders be any less demanding of
themselves?
If an amateur programmer is striving for perfection, they should be willing to examine the benefits of structured coding techniques and be open to the possibilty that there might be a better way to design and maintain the flow of their code...
Comments
That's fast, cheap, simple, etc... Often the replacement for it isn't.
Re: Anti authoritarian. Yep. Me too. If we give people enough tools to do powerful things, they will also do ugly things. Render the tools down, and we get fewer ugly things, but also not the really powerful / clever things. Nature of the beast.
That "on x goto..." is a fine example of structured programming and not really a dangerous goto at all. It is the equivalent of switch in C, other languages have their equivalents.
I allways had the feeling that messy things like switch, break, continue, abort and exceptions were put into otherwise neat "structured" high level languages when it was realized that for practical programming you really need a goto but that had to be avoided to keep the purist "goto police" happy.
Afterall the structures I mentioned are not logically necessay in programming.
Wow, lots of impassioned replies here. Maybe we should switch to a safer subject, like politics or religion...
-Phil
@Heater, yeah exactly. The purist structured approach isn't practical, and neither is the minimalist one. If the latter were true, assembly would still rule. If the former were true, something like a very clean Pascal would.
How would I replace on x goto ... in SPIN? Just got to thinking about that, and maybe I'm missing something, but we just can't do it without hackery. There is CASE, but that isn't quite the same. The math relationship on goto has is cheap, where CASE is different: is it this? or is it that? Maybe it's one of these? None of the above? .... all packed into a list. Useful and powerful in it's own way.
I like being able to relate things with simple math and operators, like we do in PASM. Often, a simple relationship can yield a nice savings. Coupla shifts and a mask maybe add, and then off to whatever sub-task makes sense. Fast, cheap, robust.
One frustration for me with structured languages is I tend to evolve programs, and I know that's due to me not authoring larger programs on a regular basis. That's a skill gap I work on when I can. But... With a goto type structure I can very easily setup a framework with "blocks" of code, and it makes sense like it does in assembly land. The same can be done with structured bits, but I find the planning difficult as well as just visualizing the logic, until I've seen it start to go.
In other words, how to structure when the structure isn't really known to the programmer? And I know in advance the most likely path is to build on the basics, until that problem goes away. Personally doing that, and progressing, but... it is a general question relevant to this goto discussion I would love to hear responses to. Maybe I'm missing something, or doing it wrong.
Getting it done ugly is preferable to just not getting it done, but doing so in a elegant way...
I took the bait in the Picaxe forum and stated my case.
Twenty nine years programming (large financial applications mostly) for large corporations (GE, Humana, Federated Dept Stores, Farm Credit Banks) gives you a certain perspective...
But never leave it in that state, and never be afraid to rewrite a block of code from scratch once you understand how it really needs to be structured. I do this all the time, even with code that nobody else will ever see, because I know that someday I will have to come back and try to understand what I did. If the program is well-structured, it's that much easier to understand and modify. I can't remember the last time I used a goto.
-Phil
Spaghetti-O's ?
Erco, go to your room!
-- Gordon
I read somewhere (I think on this forum), they weren't good programming technique. I avoided using them until I saw how Kye used them. If code can be beautiful, I think Kye's code is beautiful. It seems like he puts abort to good use. Abort traps make aborts even more useful.
I still hesitate to use them, but now I don't feel so guilty when I do decide to use an abort or a quit statement.
Duane
I have no problem with ABORT or QUIT - they terminate the method or repeat loop that they are in. GOTO type commands let you jump anywhere - not really comparable...
-Phil
http://www.youtube.com/watch?v=UkgoSOSGrx4
http://www.youtube.com/watch?v=LDHYmoDpOz8
@erco,
Aren't you being redundant?
I carried a pager for many years to support production mainframe systems and probably got beeped thousands of times during my career.
Many program crashes were caused by "spaghetti code".
One clever programmer put a display message in his program that said something like:
"This error message will never display because the condition tests will prevent this code from ever executing".
Guess what message I was reading at 3:00 a.m. .........
Or on a form? Like "Go to line 26".
Okay, now there's one GOTO I approve!
-Phil
'
A fix for the lack of a GOTO.
There is the answer.
As to using GOTOs, ain't nobody forcing you to use GOTOs. Of course, a GOTO could avoid:
while(n < 1000){ : : if(Error1){ n = 1001; continue; } : : If(Error2) return(-1); : : if(Error3) break; : : : : } /* code ASSuming a normal exit from the WHILE loop. */... and other horrors.
--Rich
Think I figured out something cool to do; I'll need to make a video off my computer monitor. Anybody have a recomendation for a screen video capture program? I found this: http://download.cnet.com/Easy-Screen-Capture-Video/3000-13633_4-10288385.html
The three escape methods you cite are infinitely better than using a GOTO. Look at it from the standpoint of the compiler writer. If a GOTO out of the scope of a loop is encountered, what to do with the control stack? Keep it intact, or pop the loop environment completely? What if, later, a GOTO back into the loop is encountered? See what I mean? GOTOs and these higher-level constructs simply do not mix.
-Phil
When this whole original debate was raging, I took on a challenge from a colleague to write an operating system for the IBM 360 without any GOTOs in PL360, a high level assembly language with only limited GOTOs anyway. There were no GOTOs and only one place in the thousands of lines of code where the program counter could be forced to an arbitrary value ... in the task scheduler where a return could be made to a higher priority task than the one that called the scheduler.
The point is that GOTOs are not necessary. They can make a program harder to understand and harder to debug. They make it harder to optimize. You can write well-structured and reliable code using GOTOs, but it's harder to teach good programming style with GOTOs. Probably the one situation where a GOTO-like control structure is particularly helpful is the abort where control has to be forced to somewhere higher in the program's flow of control. Most GOTO-less languages (like Spin) have some kind of abort mechanism.
My code will continue to boldly goto where no code has goneto before:)
From the content:
Apparently celebrity breeds contempt for authority. If GOTO were an illegal drug, Linus might well be the Lindsey Lohan of programming.
-Phil
Anyway there is also the famous argument Linus had with an accademic about the error or not of building a monolithic kernel rather than a micro kernel. I belive that occurred before Linus was so famous.
- most members in this forum most likely have never been nor ever will be employed as professional programmers (no offense intended)
- it is unlikely that their code will be modified or supported by multiple programmers (and therefore maintainability issues are moot)
- their code is not "mission critical" or likely to create injury or death (let's hope)
- some people tend to ignore facts and proven standards under any circumstance (if the shoe fits, wear it)
Knock yourself out! Type GOTO statements until your fingers cramp!It is a hobby after all - ENJOY!
PS - of course if you are writing SPIN for the Propeller, there is no unstructured GOTO type command, so too bad...
Of course, I have been programming in one flavor or another of BASIC since the 1970s...
Dave
To which I have to respond:
1. It makes no odds if you are professional or not. In other "hobby"
activities like writing, poetry, music, painting, model boat building or
whatever quite often the "hobbyist" is striving for perfection. Often they can
reach a standard that surpasses any commercial equivalent you can buy. Perhaps
the word amateur is better. Why should amateur coders be any less demanding of
themselves?
2. True. Unless they put it out on the WEB as open source then who knows what
might happen (See Linux kernel as a supreme example). Even if you are the only
one to be working on your code maintainability is an issue. I have a bunch of
projects that may get looked at very infrequently. If I have left myself an
unfathomable tangled mess then it's going to be a pain to get back into them
after a while.
3. Depends what you mean by "mission". If that christmas light sequencer does
not work when you are proudly showing it off to the family that's a serious
mission failure:)
4. True.
Only when necessary.
Here, here, let's make the best of it.
If an amateur programmer is striving for perfection, they should be willing to examine the benefits of structured coding techniques and be open to the possibilty that there might be a better way to design and maintain the flow of their code...