Go to
I believe that many programmers remember the discussion on goto and good programming style. Actually all the problem was lack of fast good quality terminals. Nowadays everybody likes anchors which are logically nothing more than another incarnation of goto. That said I am going to tell true story about goto (crawl to, really).
It was the middle of 70s. My friend S. Emel'yanov, at that time system programmer in the computer center of the Institute for Mathematics and me, a student, were trying to install REDUCE-2 on IBM360. Actually it was "russian analog" of IBM machine with incomplete and poorly translated documentation. Core memory was 512K and REDUCE demanded 400K at least. So one night we declared "system maintenance time" threw out all the user programs and utilities not necessary for the continued operation of the system and gave it a shot.
Not enough memory! I don't rememeber exact error message. It was not very useful, it merely recommended to call a system programmer. Thanks! Fortunately we had the sources. We decided to print the relevant part (approximately 50m of folded paper) and look through all calls to getmain (as far as I can remember this was the name of the function).
The corridor was long enough for us to spread out our paper and we start crawling back and forth locating all calls to getmain and trying to understand what every one was doing. At that time I thought that goto really is one the Devil's major triumphs.
We found it. The input buffer was too small. We used to work with cards so we've automatically defined in JCL - Job Control Language (Oh, where it is now?) buffer size as one card (or line if you prefer it this way). However, by default REDUCE attempted to read a block of 20 or 24 lines at once.