GOTO, Goto & Goto - Computerphile

TL;DR

GOTO statements are problematic in higher-level programming because they obscure a programmer’s intent, while constructs such as while loops make that intent explicit. The UNIX kernel’s C implementation needed only a few dozen lines of assembler, greatly reducing jumps compared with an assembly implementation. The speaker connects this programming lesson to a Rubik’s Cube demonstration using remembered twist operations; read on for the distinction between unavoidable machine-level jumps and clearer high-level code.

Transcript

I think it was a sort of major achievement for eunuchs actually that you know it's its big claim to fame is yes we Dennison can we wrote the UNIX kernel in C we had to have a few dozen lines of assembler and maybe somewhere in there there's the odd sprinkling of go twos and there's good excuses for it sometimes in the heart of an operating system b... Read More

Key Insights

• 👨‍💻 Writing the UNIX kernel in C reduced the need for go-tos, improving code readability and maintainability.
• 🎚️ Go-tos are essential at the assembly language level but can become problematic in higher-level languages due to a lack of documentation and clarity.
• 👥 Solving a Rubik's Cube using go-to maneuvers requires knowledge of algorithms and group theory principles.

Questions & Answers

Q: What is wrong with using GOTO in higher-level programming languages?

A GOTO transfers control without necessarily explaining why the jump occurs. The speaker argues that programmers often fail to document that purpose adequately, making the code harder to understand.

Q: Can GOTO instructions be eliminated completely?

They cannot be eliminated at the assembly-language level because machines operate by transferring execution to different addresses. Higher-level languages can hide those jumps behind clearer constructs, but compiled assembly still contains branches or jumps.

Q: How do while loops improve on GOTO statements?

A while loop makes it clear that control flow represents repetition governed by a condition. When compiled, it may still become jumps in assembly, but the high-level source preserves the programmer’s intention.

Q: Why was writing the UNIX kernel in C considered a major achievement?

The speaker says the UNIX kernel was written in C with only a few dozen lines of assembler. This massively reduced the number of explicit GOTOs or jumps that an assembly-language implementation would have required.

Q: Are GOTOs ever justified in an operating-system kernel?

The speaker allows that an occasional GOTO can have a good justification in the heart of an operating system. Even so, using C for the UNIX kernel reduced such jumps substantially.

Q: Are GOTO, jump, and branch different concepts here?

The speaker treats GOTOs, jumps, and branches as essentially the same underlying idea. Each redirects execution to another instruction or address.

Q: How does the Rubik’s Cube demonstration relate to GOTO?

The speaker uses cube operations whose name sounds like GOTO, turning the programming discussion into a wordplay-based demonstration. The operations twist selected pieces while leaving the rest of the cube invariant, and repeated twists eventually return corners to the same position.

Q: How many Rubik’s Cube algorithms does the speaker remember?

The speaker estimates that someone needs about 90 algorithms to become moderately good at solving a cube very quickly. He remembers about 10 or 12, accepting that his method is suboptimal because those algorithms are easier for him to retain.

Summary & Key Takeaways

• The speaker reflects on the achievement of writing the UNIX kernel in C, eliminating the need for excessive go-tos.

• Go-tos are essential in assembly language and machine code, but their use in higher-level languages can lead to code complexity and lack of clarity.

• The speaker demonstrates solving a Rubik's Cube using go-to maneuvers, highlighting the process and the challenges involved.