On Jan 10, 2011, at 11:13 AM, Luther Fuller wrote:
On Jan 10, 2011, at 10:50 AM, Mark J. Reed wrote:
On Mon, Jan 3, 2011 at 11:27 AM, Skeeve <email@hidden> wrote:
We mustn't rely only on quoting someone because they are accomplished. They can be accomplished and have an opinion that is incorrect, was great at the time, but is no longer, or one that the reader is misinterpreting.
If you read the link, you'll see Knuth referring to many noted programmers of the day eschewing goto statements.
If you read closer, you'll see that he's not really disagreeing.
"In other words, it seems that there is wide- spread agreement that go to statements are harmful, yet programmers and language designers still feel the need for some euphe- mism that "goes to" without saying go to."
It's that programmers "feel the need" for a goto like thing.
Goto is a case of "this condition is reached, please go to the spot where you can execute this code".
This, alone is nice, but what it does not address is when people get super sloppy and are using goto to jump all over the place creating knotted spaghetti code.
The concept of a goto should fit within neatly structured and organized code that had been properly subclassed or encapsulated.
Where an instruction "goes to" should be easily traceable and identifiable. The complexity around it should be reduced to allow the code to be easily modified and debugged.
This is why I put my sound managing routines in their own object class, declare the public handlers to them and only worry about calling the public handlers/methods.
If I had this within one big logic statement, it would be a total recipe for "ease of breakage".
In short, once you are able to make the leap to organized design, you'll find the need for goto (as you knew it) to diminish, your programs will be more debuggable and easier to maintain.
Computers are fast enough today not to worry about the speed of every if statement. Use this reality to your advantage and structure and organize your code or you'll be forced to go to your room with no desert.
Goto is not inherently evil, and Dijkstra may have overstated his case, but the point stands. In 1968 people were writing code to maximize efficient use of space. Things got moved around, and you wound up with control flow that was nothing like the order of the source code text. That's what they mean by spaghetti code.
I recall doing a bit of Basic programming many, many years ago. 'goto 456' lacks description. On the other hand, 'do mountSparsebundleDisk(...)' is informative. And it's easy to return to the calling point.
The occasional goto can be quite liberating, saving you from having to exit out of deeply nested loops or conditionals or whatnot.
The only 'goto' that I found liberating in AppleScript is 'error number -128'.
Yeah, but as we all probably started out in a non OO language. Don't gotos promote sloppy approaches?
Pure structured-programming advocates look down not only on goto, but also on break ("exit loop", "last", whatever your language calls it), insisting that loops should have only one entry and exit. In my experience that often means most of the code is deeply nested inside some conditionals and indented halfway across the page. So a purist I ain't. :)
Most of the deep nesting in an AppleScript repeat loop could be avoided if there were an 'next repeat' command in AppleScript.
There is a way to do that if you're looping through an index. Simply add 1 to the index. But yes, next repeat would be rather nice.