3 ms·
> The argument for structured programming was made and won in the '60s Most code out there is fine using break and continue in loops, and early returns are pre
by cwzwarich 8y ago
> The argument for structured programming was made and won in the '60s
Most code out there is fine using break and continue in loops, and early returns are pretty popular. All of these are unstructured programming (by the 60s definition). I don't think it's all that clear that it has won.
- scott_s 8y agoThe author anticipates this point, and rebuts it: "In the end, modern languages are a bit less strict about this than Dijkstra's original formulation. They'll let you break out of multiple nested structures at once using constructs like break, continue, or return. But fundamentally, they're all designed around Dijkstra's idea; even these constructs that push the boundaries do so only in strictly limited ways. In particular, functions – which are the fundamental tool for wrapping up control flow inside a black box – are considered inviolate. You can't break out of one function and into another, and a return can take you out of the current function, but no further. Whatever control flow shenanigans a function gets up to internally, other functions don't have to care. This even extends to goto itself. You'll find a few languages that still have something they call goto, like C, C#, Golang, ... but they've added heavy restrictions. At the very least, they won't let you jump out of one function body and into another. Unless you're working in assembly, the classic, unrestricted goto is gone. Dijkstra won." I tend to agree with the author. Linux kernel code, for example, uses goto for error handling, particularly when implementing system calls. But the author is correct: the gotos can't jump out of the function. Readers can still infer control flow from function call sequences. I quite enjoyed the post, I think it's worth giving the author's claims serious consideration.
- mannykannot 8y agoPutting aside pedantic purity arguments, structured programming has come to dominate high-level-language design and the way we think of programming. Programs like the FLOW-MATIC example from the article are simply not being written any more in any HLL. Few (if any) concepts have achieved greater ubiquity.