Intel x86 considered harmful – survey of attacks against x86 over last 10 years

goto is just a mnemonic for jmp. It's the primitive from which all higher level control flow is ultimately derived. It isn't harmful, and it's used a lot even in C.

You're missing the reference - Dijkstra wrote a famous letter on GOTO in 1968 which was published as "Go To Statement Considered Harmful":

https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

In context, it was a piece advocating against the use of GOTO to the exclusion of all other control structures (e.g, 'for' or 'while' loops, etc).

I appreciate you thinking I'm a buffoon who was born yesterday and hasn't heard of EWD215, but it appears your reading comprehension is, to be charitable, iffy.

wyager's statement, involving PHP (for which there is not a famous "considered harmful" essay to the best of my knowledge, though there is "A Fractal of Bad Design") and goto statements, was a rather clear implication that both constructs are innately harmful in an attempt to counter n0us' assertion that influential/popular technologies imply a high quality. There was nothing said about using goto statements in presence of structured programming, but merely goto as an intrinsic badness. This is a common belief cargo culted by a many naive commentators and XKCD readers who do not realize that all control flow is derived from goto, and moreover that even in some languages with structured control flow it is still useful, e.g. for resource cleanup and breaking out of nested loops.

>Be civil. Don't say things you wouldn't say in a face-to-face conversation. Avoid gratuitous negativity.

https://news.ycombinator.com/newsguidelines.html

My statement was neither something I wouldn't say face-to-face, nor gratuitously negative.

> [goto] is the primitive from which all higher level control flow is ultimately derived

I'm pretty sure you cannot implement conditional branches using unconditional branches as a building block. Unless you count indirect branches, which goto usually doesn't support.

That largely misses (Dijkstra's, originally) point. How control flow is implemented at a low level (e.g. jmp/lngjmp) is a completely separable from how it should be exposed in a language.

Wearing a c programmers' hat you may say "absolutely", a scheme programmers' hat, perhaps "no way". Horses for courses after all.

That's a more nuanced position than the one that is commonly understood, however. Though, you are always bound to your architectural model, so exploiting it more directly is not innately bad. Layers tend to be leaky.

Wearing a Scheme programmers' hat, call/cc isn't any less of a landmine.

Not that I'd recommend it, but sure you can. Just allow modification of the code to include where you want to jump to. :)

Scarily enough, I think this used to actually be somewhat common place and is why many functions were not reentrant.

Isn't that more aptly stated as "implemented with" not "derived from"?

Assuming a von Neumann or modified Harvard architecture where execution advances from an incremented program counter, I'd say derived from, though it may be that the former is more appropriate. It is certainly not universal, I do not make that claim.

It comes off as unpalatable, to say the least. You were assuming malice in the other poster and then went on a minor tirade without sufficient prompting.

The program counter doesn't typically appear in the programming languages that have (or don't have) goto. You're talking about implementation, but I think people typically criticize goto in terms of semantics (iirc, I can include Djikstra in that camp, but I never made a super-careful study of that paper).

It's a matter of scale. If you're trying to compute absurdly large numbers, you'd be a fool to use addition, even if it is fundamental to some other operation you want to use. Goto is problematic not because it can't be used effectively, but because it won't be. Because it doesn't encapsulate a powerful enough abstraction to make computers smarter or programs easier to write and understand.

If you have to write a goto, you can drop into assembly. Don't add it to your high-level language, because it doesn't add anything there, it just gets in the way.

"It's the primitive from which all higher level control flow is ultimately derived."

There are a billion alternative primitives from which you could derive all the same things. Goto is not special. And it is so primitive, it is not hard to write something else and have a compiler translate it. You shouldn't need goto anymore than you should need access to registers.

The comment being replied to was also rather uncivil by a certain definition, assuming the commenter was unfamiliar with what is by now very cliched literature and explaining it in a somewhat condescending tone, as if to a child, when in truth there was a very substantive point being made.