Survey of Modern Programming Techniques
Robert W. Bemer · ITNOW · 1961
In the business section of the New York Times there often appears an advertisement (not of my own company) for “Research Programmers to work in Macro-Assembly language development, Heuristic Programming and Artificial Intelligence studies, Symbol Manipulation and other advanced computer areas.” You may have seen it. Even the lowly Machine Programmers are requested to “write programs for a variety of large-scale digital computers in the areas of Scientific Information Processing, Natural Language Processing and Information Retrieval Systems.” At first this may sound like somebody has been reading Mr. Potter’s books and this is merely one-upmanship in the programming area, but I assure you this is not so. Programming has indeed moved to glamorous heights. Until about four years ago, programming was a more homogenised profession. This was to be expected in a relatively new field. However, so were the developments outlined in this advertisement. At present we have a large number of programmers in the world, certainly over 30,000, and the techniques used range from the ones described down to the most archaic. It is extremely unfortunate that the archaic end is the large end of the iceberg—the part under water. This is occasioned by the sheer rise in production programming, particularly in (but not restricted to) business and scientific applications. The production of generalised systems such as the Fortrans, Flowmatics, various assembly programs, and rather complete systems like Sos for the 709 is a very big business. I hope that the end-purpose of this talk (and others like it, with published articles on the topic) will be to raise this vast body of programmers from the doldrums of outmoded techniques. I realised in 1950, after my first year with electronic computers, that the leverage factor between a good and bad programmer, or a good and bad technique, can easily be as high as ten or twenty-to-one. In a tricycle factory one is likely to become vice-president for increasing the output 10% at the same manufacturing cost. In programming, a 10% betterment of efficiency—that is in construction, not running efficiency—is likely to go unnoticed.