That book was published after I had already retired and ceased to be a productive member of society. So it never came into my orbit.
It’s probably good guidance for those managing an IT environment similar to that at Google, but may not have more general applicability since I assume it’s focused on the web paradigm where systems perform relatively simple functions for massive numbers of users. Which is not the same as systems where “large” refers not to transactional capacity but to the size and complexity of the code base. It probably also doesn’t address one of the challenges I sometimes faced, which was designing to a specific level of high availability, so the software architecture had to incorporate the parallel operation of redundant computing hardware.
The Glenford Myers book I mentioned was instrumental in inspiring some lasting ideas about good software design, particularly the idea of structuring the components of large software systems as hierarchical levels of abstraction with clearly defined abstracted functions at each level and well-defined interfaces between them. Happily, it’s also an approach easily adaptable to distributed computing using message queuing.
It is really not that difficult to structure a loop in a high-level language so that it logically converges on its proper exit and works fine without having to rely on BREAKs. One simply has to develop composition habits that naturally trend toward elegant code, after which using GOTO-type instructions eventually starts to feel just wrong.
In most RISC assembly, opcodes that generate actual direct address branches are not even available. If you are using some kind of fancy assembler that synthesizes an op with multiple instructions, you might be able to put in direct address JMP-like instructions, but most of the time branching is relative and code is typically relocatable.
But, no one works in assembly any more. Looking at compiler output, it is obvious that dicking around at machine level is wasted effort, when one can write ridiculously verbose high-level code that easily condenses down to better assembly code that one could construct by hand.
Entirely agree, with the slight exception that BREAKs can make some code more readable, or are part of the control-structure form as with some CASE statement syntax. Even the case for readability is questionable. It wouldn’t apply to what I consider valuable code. More for dealing with some arbitrary rules or exceptional cases.
There many perceived language deficiencies that I consider nothing but compiler issues.
The Art of Computer Programming has plenty of RISC assembly language. Of course, that is a textbook on fundamental programming, not on how to write domain-specific high-level apps.
I’d call that a pedagogical example, not a real RISC machine. I’d call Knuth more a brilliant description of the fundamentals a programmer should know, not a book about the fundamentals of programming. When I was in grad school, everyone read Knuth.
So it never came into my orbit.