Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.

As expected, a moron just managed to prove his complete lack of ability to think. Applause! You're incompetent. Admit it. People like you should not be allowed to code.

No way. Switch is semantically more complex, and if you want to implement state machine over it, you need to introduce additional entities - namely, current state variable. And, in case of C, there is a horrible way to fail by forgetting a break statement - which also has nothing to do with the essence of a mere state transition.

Are you deliberately avoiding commenting on OCaml bytecode interpreter example? Show me the "better alternative", or admit that your so called "experience" is deeply flawed and very limited.

OCaml is a live, thriving project with many new contributors. It's perfectly maintainable, and, in my books, an example of the perfect C coding style. Linux has megabytes of commits every week. Far from being "dead for decades". So, what are you talking about? What's the point of generating code which is perfectly readable anyway? State transition is, essentially, goto. Any higher level language will feature the semantically equivalent construction to represent state transitions. Yes, arrows in your UML are not any different from goto.

Threaded OCaml bytecode interpreter is several times faster than the switch-based one. Far from being "a very small speed increase".

Funny. It was YOU who brought the correctness and verification issue up. I would never imagine mixing it into a goto discussion. Proving code correctness always involves operating on CFG, no matter if it is a manual or automated proof. Your precious structured coding constructs are eliminated long before you can do any useful reasoning about the code. For a "single example", are you blind?!? Never seen Linux kernel? Then how can you refer to your nearly non-existent "experience"? Or, take this code and make it better: [^] I am 100% sure you cannot keep the same performance without goto. Show me that pathetic "better alternative".

Goto "debate" is not over. Dijkstra had a bit of trolling, and now hordes of incompetent dummies are taking his jokes as some kind of sacred revelation. There are *no* arguments against goto, besides complete ignorance of the opponents. I pointed to several code examples which absolutely *must* use goto. And you, goto haters, as usual, ignored the uncomfortable truth. Mind explaining, how would you rewrite OCaml bytecode interpreter without goto? Code is here, in case if goto haters are as low as I suspect and cannot even use google: https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c[^] And please, mind explaining, how exactly this Knuth's code is "unreadable": http://www.literateprogramming.com/adventure.pdf[^]

Mind naming a language feature which is semantically closer to the notion of "state transition" than a simple goto?

Take a look at this decades old code - I bet you can easily read it: http://www.literateprogramming.com/adventure.pdf

What? SSA transform is performed on a CFG, and it absolutely does not matter if there are irreducible sub-graphs in the flow. Not to mention a trivial fact that irreducible CFG can always be transformed into a reducible one by subgraph cloning.

rgrep goto /path/to/linux/kernel/sources; git blame each of the hundreds of occurrences, and then try to convince those who committed that lines that they are worse coders than you are. Chances are, you're going to fail miserably.

Nearly all the static code analysis tools I know are operating on a CFG level (i.e., nothing but conditional and unconditional gotos). So, how exactly having an explicit goto may hinder code verification? And there are many benefits in using goto. Pity you failed to notice them in the past 30 years. Chances are, you never implemented a state machine or a threaded code interpreter, and you never generated code from a high level DSL.

You are so ignorant. Mind explaining, is the OCaml byte code interpreter really can be dismissed as an example of a "bad code"? Or you simply failed to think of this particular way of using goto?

Because they are ignorant idiots. Goto is absolutely essential in a number of cases. Most notable are: - Implementing state machines. The closest construction to state transition is goto, so it must be expressed as goto. - Various generated code (from higher level languages/DSLs)

You just confessed that you do not understand scripting at all. How were you "running scripts" then?

Funny, how windows-minded people are struggling to comprehend such a simple thing as Unix Way. That's why automation is something nearly unheard of in the windows world.

Pass a path from one .bat script to another - I bet you'll be lost in escaping in no time.

Point of Cygwin is to make Windows at least a little bit usable, because without the normal scripting tools it was just a shell for running Word (which is itself pretty useless too). Removing spaces from the "standard" paths is a tiny price for such a huge value.

You're free to use spaces in paths, of course. Just never expect any scripts with string escaping work with them. No matter what your OS is. Something is terribly broken in the heads of those who allows spaces in the paths - they're making it nearly impossible to deal with their infrastructure with any scripting environment. COMMAND.COM chokes on spaces too, by the way.