EDIT: Never expected this to devolve into an argument about the merits of gotos! I thought we were all past that, but apparently not.
I suggest reading the actual "goto" paper sometime… it's a classic.
But I do think the while+switch representation is superior.
state = START;
break;
goto start;
But it does make for the same exact behavior.
It might not be called goto, but isn't setjmp/longjmp essentially the same?
You can do some dangerous things with longjmp to implement coroutines, but it's horribly non-portable.
Writing state machines is one of the moments when the 1d top-down method of programming really hurts. I feel like I can easily understand an FSM drawing, but splay it out in code and it's difficult to track.
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...
All the arguments it makes no longer apply but people still quote the snappy headline.
That essay does make an excellent argument against programming with many tiny functions though, as those do cause the execution cursor to jump all over the source code document.
Nothing. But the thing they want to do -- altering the datastructure on the fly -- is not the best way to solve the problem.
I would solve this by writing two functions: one that creates an array from a binary tree, and one that creates a doubly-linked list from an array.
Would this use up more RAM and take longer to run? Yes
Would the code be easier to understand (and therefore more bug-free)? Yes
Many programmers treat 'goto' the same way that we treat radioactive waste, but they don't know why. Perhaps it is a holdover from courses with teachers who automatically graded 'fail' on programs that used a goto. Perhaps the programmers have only heard that gotos were bad.
Sometimes 'goto' is the correct answer. For state machines it can be an pretty efficient technique. For "ordinary" code it is sometimes the best way out of a situation (e.g., busting out of a deeply nested set of loops).
The "Goto considered harmful" movement came out of the 1970s, when GOTO was used all the time and the normal state for a big project was abject spaghetti. I think we can all agree that was a very bad thing. But the utter avoidance of goto is an overreaction that seems to be based on unreasoning fear, or toxic peer pressure.
so, goto is efficient at escaping inefficiently structured code? That doesn't make it really efficient. I mean there's a reasonable rule of thumb: don't indent the code too deep. Because what you are talking about is one kind of spaghetti, the kind cut into digestable chunks. The interleaving of active and inactive blocks leads to unreadable code sooner or later.
Of course this type of dogmatism gives us FP gems akin to [eating] a piece of Sushi with a steak knife.
Functional programming as a paradigm makes sense when you want to limit the context a programmer has to be aware of when working on a problem, but in this case recursion and imperative programming accomplish the same goal.