A great number of familiar concepts are described here in just 2 pages:<p>- Subroutines<p>- Modularity<p>- Unit testing<p>- Reusable libraries<p>- Documentation<p>- `goto`/`return`<p>- Debugging<p>The tone seems to place this writing as instructive -- someone who wanted to write a programme at the time could refer to this document for hints at what to do. Very interesting window into the past.<p>I haven't quite decoded exactly what the modern formulation of an `interpretive routine` is. Is it the same as the layer we would now call the "instruction set architecture" that sits above some "microcode" operations? Where some instructions do more work than others behind the scenes. It also seems to have some relation to "just-in-time compilation", just at a lower level than the current systems.
Besides describing programming concepts, this paper reveals what it was like to be a programmer:<p>As I understand it, it was expected from a programmer to completely understand workings of the algorithm and a tracing subroutine seems to not be in favor. Currently the systems we're working with are so complex that we can't comprehend all algorithms and need to use debugging and tracing tools:<p>> However the interpretive routine retains control and so it is possible to print out extra information about the course of the programme. This extra information makes it possible to follow the meanderings of the program in detail thus helping to locate the errors of a programme. This is not a good method of finding errors in programmes as it takes a long time and the programmers knowledge of the programme is not utilized - as it should be - in
tracing the fault.<p>Other bits I enjoyed reading:<p>Writing good docs was hard even back in 1951!<p>> there still remains the considerable task of writing a description so that people not acquainted with the interior coding can nevertheless use it easily. This last task may be the most difficult.<p>Timeless piece of advice<p>> All complexities should - if possible - be buried out of sight.