We Are Sorry to Inform You (2005)
fang.ece.ufl.edu
fang.ece.ufl.edu
To me, the peer reviews look like something you might get from a reviewer today, but I'm certain the Einstein's performance review linked on the very top is fiction.
No
It made perfect sense back when people were writing BASIC full of "GOTO 110" and "GOTO 520" that resulted in a tangled mess. Unfortunately it caught on so well that it resulted in people being really obsessive about it, and rejecting every single instance of it in C code, even in places where it makes perfect sense and makes the code cleaner.
Dijkstra was wrong with his “goto” paper. It’s fine to admit that. He was right about most other things.
> The paper doesn't explain to us what would be the use of the "if" statement without a "goto" to redirect the flow of execution: Should all our postconditions consist of a single statement[…]?
switch n{case 1: case 2: case 3:}
goto n*100+1000
And then there was the hidden advanced troubleshooting console:
input N: GOTO N choice /c abc
goto choice%errorlevel%
:choice1
:choice2
:choice3
set ops=a b c
set op=%1
for %%p in (%ops%) do if "%op%"=="%%p" goto %op%
goto usageThe "goto cleanup" idiom to do deferred work (I don't like defer or finally in languages which have them, but at least these are language constructs which say what we wanted, the goto cleanup idiom only achieves that in some very easy cases, in more complicated cases your actual intent will be unclear)
The "iterator escape" idiom to get out of some larger iterative operation we're doing because we just realised we want to give up / found the overall answer. This is lack of imagination in the language's / library's / eco-system's control flow semantics and is one reason I really like Rust's core::ops::ControlFlow.
Code shouldn't require imagination. Sometimes the simple and readable solution is just better.
Doing if(condition) return at the start, before it gets going often reduces indentation and how many branches you need to see at once.
But I can agree sneaky returns can bite you sometimes
I occasionally have a couple of returns in one func but only for very, very simple and short funcs where it's clearer.
I dunno. Perhaps the problem is we're missing some higher level procedural construct - any ideas?
Examples I was thinking about:
* an early return can only go back to the call-site
* all returns in a function or method return to the same place
* an early return terminates the context it is in
* an early return does not create an entry point for nearly arbitrary other code points as labels for gotos do
Those few places where they appear in (what would have been) defensible C code are better served by reliance on destructors. I.e., it is much better to start compiling the C code with a C++ compiler, and then clean it up.
- In some very performance sensitive cases. It helps you skip a bunch of extra checks or variables.
- When you need to convert recursion to iteration, but want to keep the code structure mostly intact so you don't mess up the source control history.
Nowadays I will use lambdas that return early in preference to goto. Not from fastidiousness so much as to avoid confusing the optimizer.
Poster child for reprehensible use of goto is procmail.
A side note: the GOTO paper is misunderstood by modern (non-)readers, much as the writings of Adam smith would horrify most of his contemporary advocates. At the time Dijkstra wrote it, it was common for functions to have multiple entry points as well as multiple exits (as they still do today). In addition, due to the limits of memory, the importance of the not yet named DRY principle was extreme, not for today’s reason (clarity and maintainability) but simply to use less program memory, so people would jump willy-nilly into unrelated blocks of code just to avoid writing stuff out. You can still do these things in assembly (as was common back then) but modern languages make it hard to do.
> Electronic mail on the Arpanet is indeed a nice gizmo, but it is unlikely it will ever be diffused outside academic circles and public laboratories—environments in which the need to maintain confidentiality is scarcely pressing. Laboratories with military contracts will never communicate through the Arpanet! Either normal people or small companies will be able to afford a VAX each, or the market for electronic mail will remain tiny
The irony of course is that any non-original copy of a document presented in person is a 'fax' (facsimile)!
Well, that is what happened. PCs were definitely as powerful as the older VAXes right around time the Internet opened for business. They just weren't running the VAX OS.