If you want a spoilery TLDR:
It's more about the journey. He tracks down the origin, finds the support, finds the support flawed, and leaves you to your own conclusion rather than make a new flawed one.
The basic idea is that the origin assumes a highly critical inner hot loop, don't assume where it is, and optimize there.
There's some other time spent saying this justifies slower abstractions for maintainability elsewhere.
Another point I liked was that there was, apparently, an influential book called Structured Programming, whose content was so universally agreed upon, that all programming became Structured Programming. Nobody needs the book anymore.
No, they're not sarcastic. It was an interesting point; if an idea succeeds well enough people just do it and make it "common sense". It's a point in the talk.
It's not the focus of the talk and so it's hard to tell if Casey understands (the choice to separate the words GO TO in several places suggests he does) but the `goto` keyword you've seen in several modern languages is not the problematic "GO TO statement", it's a de-fanged remnant, the toy poodle to GO TO's wolf pack.
The actual GO TO complained of is, like the jump instruction in machine code, just entirely unbothered by context. Want to go from the middle of this code about employee payroll processing to mid-way through initializing a weather simulation? No problem. Well. No problem for the machine, for a human programmer it's a complete nightmare. Actually that's putting it mildly, nightmares have more structure. You cannot do anything like that with for example C's goto.
You compiler can, and in a few cases (that's what the discussion about the tail-call optimisation is about for example) it will, but the program you wrote doesn't do this and so you don't have to try to keep the whole program in your head.
So in that sense GOTO died out with, maybe BASICs? I think the BASICs tend to have that wolf nature GOTO feature, but nothing modern has it.
So, I have never seen anyone actually use GOTOs, so maybe a lot of the stigma comes from excessive, poor usage or something.
However, having written a good chunk of ASM in my life. I don't think jumps or branches are really that hard to follow. Jumps/Branches and GOTOs specify the next location. It is not as though one has to guess where.
It's not the arrow, it's the archer that is the problem.
Never as in, in BASIC, or you've never seen goto in C? The de-fanged C "goto" is all over the place in Linux and in similar close-to-metal C software. C does not (yet, likely C2Y will fix this) have labelled break, so goto is used to say "I am inside a mess of nested loops, we're done, end the loops" and as a catch-all failure handler in some codebases.
My guess is that your ASM is inflected by structured programming everywhere. Yes, unlike COME FROM we can see where we're going next with GO TO but if you go back 60+ years there is some scary code that even today's optimizers probably wouldn't emit because it's too crazy. Suppose calculate-total-fuel ends with three CPU instructions which copy register F into register H then add register C to it and multiply the sum by four. Over in locate-horizon it so happens we need to add two things together and multiply them by four and we could do that last. So, if those two things were in registers F and C we could just GO TO that last part of calculate-total-fuel.
You're correct that we don't need to "guess where" it goes, but good luck understanding why the program works when it's like this, let alone the ordinary maintenance work of making small modifications.
> My guess is that your ASM is inflected by structured programming everywhere.
I think you're probably right. To expand on this:
In asm, you can have things that are clearly functions. You have a stack discipline going in and out of them. They end with stack cleanup, then a RET or some such, which pops the return address off of the stack and jumps to it. Within that function, you have JMP instructions (or whatever) that move around within the function. You may also call other functions, by pushing variables on the stack, and then calling JSR or whatever to push the program counter on the stack and jump, and when those functions return, you'll be right where you were in this function. That's all sane, and it's "structured assembly".
Non-structured assembly would be like the example in your second paragraph. You're in one function, and you JMP (not JSR) into the interior of a second function. Or, you simply don't have functions, just labels that you jump around do. That's not structured, and not sane.
I have no idea what the parent meant by, "My guess is that your ASM is inflected by structured programming everywhere."
(I am the GP)
Your response was far better than mine. If those instructions were executed more than a couple of times and the constraints/assertions were identical, I'd absolutely throw them in a function. I'll handle what I need to before/after the function.
I would never branch to some coincidental label. That is why I love ASM so much. If you are sloppy or lazy, you will most likely be punished severely for those choices.
(Tangential, but when I first learned ASM in college, I felt like I learned more in that one semester than all the sum of all classes in my entire degree.)
To be honest, I do not have much experience with C nor BASIC. I only know the extreme basics of C, and I have never written a line of BASIC in my entire life. My first real exposure to programming was in high school (Java). From there, I basically went from high-level languages -> x86 -> high-level languages again -> starting to play with AArch64 in an attempt to but some grooves back in my smooth brain.
> My guess is that your ASM is inflected by structured programming everywhere.
I am not certain what you mean.
> if you go back 60+ years there is some scary code that even today's optimizers probably wouldn't emit because it's too crazy.
Why was this as common as the allegations lead me to believe? Was it just a product of time? No better way to handle such logic at the time?
As for your example, I know it is intended to be interpreted trivially, but I just want to clarify I understand you correctly. Is the issue due to locate-horizon depending on logic from a completely orthogonal operation?
If so, I see the red flag immediately. However, I do not see an issue with creating a separate function. I'd just have to be damn sure H was not storing anything used for some other upcoming operation prior to the function call, I'd check F and C for valid state (if necessary), take other potential side-effects into account, etc.
It feels a lot like the DRY advice being abused in higher-level languages, you know? I agree with expression, "duplication is better than the wrong abstraction."
The basic idea is that the origin assumes a highly critical inner hot loop, don't assume where it is, and optimize there.
There's some other time spent saying this justifies slower abstractions for maintainability elsewhere.