7.9KB
The Psychology of Computer Programming — Interlude: Part 4: Programming Tools
- Source: /library/The Psychology of Computer Programming/source-file.pdf
- PDF pages: 257–262
- Pages without text: 258, 259
- OCR note: OCR is supplied below for image-only pages; multi-column reading order may be imperfect, so consult the PDF for layout and visuals.
- Note: Part introduction and Silver Anniversary comments on the part.
Ka a Fa “Py ine Be ae a4
- ves siya ‘ a a ae pie ae I, gas Pn to, re cy
- sd
- ee
- i
- BAe
- ae
- an
- wit
- iy
- .
- «
- his
- +
- AR
- A
- Mie
- ee
- NY Lae ok i u b Lien " 4 j i MU od ah oe ; .7 rN we : an . Ms
[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
PART TOOLS
[OCR from image-only PDF page; verify layout and illustrations in the PDF.]
a word of advice to such of my hearers as may happen to be professors.I am allowed to use plain English because everybody knows that ! coulid use mathematical logic if I chose. Take the statement: “Some people marry their deceased wives’ sisters.” 1 can express this in language which only becomes intelligible after years of study, and this gives me freedom. I suggest to young professors that their first work should be written in a jargon only to be understood by the erudite few. With that behind them, they can ever after say what they have to say in a language “understanded by the people.” In these days, when our very lives are at the mercy of professors,I cannot but think that they would deserve our grati- tude if they adopted my advice. BertrandRussell* f the poor workman hates his tools, the good workman hates poor tools. The work of the workingman is, in a sense, defined by his tools--witness the way in which the tool is so often taken to sym- bolize the worker: the tri-square for the carpenter, the trowel for the mason, the transit for the surveyor, the camera for the photog- *Taken from Portraits from Memory,Copyright 1951,1952,1953 and 1956,by Bertrand Russell. Reprinted by permission of Simon and Schuster and George Allen and Unwin, Ltd. 203
204 Programming Tools rapher, the hammer for the laborer, and the sickle for the farmer. Working with defective or poorly designed tools, even the finest craftsman is reduced to producing inferior work, and thereby reduced to being an inferior craftsman. No craftsman, if he aspires to the highest work in his profession, will accept such tools; and no employer, if he appreciates the quality of work, will ask a craftsman to accept them. Is the situation any different in programming? At first glance it may seem to be, but this misunderstanding can be traced to the relative im- maturity of programming as compared to other crafts. The tools of any trade evolve, but the tools of programming have had but a decade or two to arrive at their present forms. Thus, there is no common standard for programming tools, and no common experience in the use of the best tools that do exist. The programmer who is working in machine language—and many more of these still exist than is commonly supposed—may not even be aware of the advantages that the crudest assembly language can provide. In our course on the psychology of computer programming, one of the students undertook an analysis of more than 2000 programming errors encountered in his shop—where all programmers were coding in machine language for a small special-purpose machine. Of these errors, 65 per- cent were attributable to such housekeeping matters as inserting the wrong number of no-ops for delay cycles, incorrect operation codes, er- rors in placing a bit for such features as indirect addressing, using the wrong absolute address, or incorrectly calculating a displacement. By using an assembly language of the most primitive design, these program- mers could have eliminated two-thirds of their coding errors—but they did not even know that such a thing was possible. As we move up the levels of possible programming aids, we find the situation repeating itself, for although the assembly-language programmer may scoff at the machine-language programmer, he may be in turn the object of amusement for the user of a language with macro facilities. Not all of this titillation, however, is attributable to the superiority of one system over another. Much of it, indeed, is a way of concealing an insecure feeling that one’s own programming system might not be, after all, the pinnacle of man’s technological achievements. In this section of the book, we shall attempt to examine the major tools used by the programmer from the perspective of psychology, in order to see if we cannot put questions of system design and selection out of the reach of ignorant squabbling and squalling. No doubt we shall be unable to achieve this high aim, but we hope to make at least a start in a direction which promises more than some heretofore explored.
Silver Anniversary Notes —X Comments on Part 4: Programming Tools When my old-timer’s eyes gaze upon today’s programming tools, | drool— hopefully not merely out of decrepitude. Ah, imagine what we could have done with such tools ...! Well, actually, we’d probably do just what we did, and what any true professional would do—build more tools. For most of my early career, | was engaged in building tools—operating sys- tems; debugging tools; performance analyzers; static and dynamic code analyz- ers; test generators, harnesses, and simulators; database systems; interpreters; and the like. Notice the omission of compilers. For some reason, the field of compiler-building never attracted me. There always seemed to be enough peo- ple building compilers. That much hasn’t changed; there are still more than enough compiler-builders. | did, however, have a great interest in supplementing compilers with metalan- guages and other tools, so | made an excursion into MetaCOBOL. With my coauthors from Applied Data Research, | wrote a book about MetaCOBOL, High-Level COBOL Programming. The book was an experiment in using a macro language as a transition device from COBOL to something better. On the whole, the experiment didn’t work, and it was my last major effort at supplement- ing languages with tools. Superior tools only prolong the life of inferior lan- guages. For some years, | wrote a syndicated column for professional programmers as a way of inspiring better tools and better use of existing tools. Some of these
PZ Silver Anniversary Notes columns are collected in Understanding the Professional Programmer and Rethinking Systems Analysis & Design. | doubt that these books and columns had any measurable influence on the development of better tools—certainly not compared with the influence the personal computer had. Back in the 1950’s and early 1960’s, programming tools were largely designed and made by users. For example, when we built the very first operating sys- tems, we did so as a cooperative effort among various IBM customers. IBM was involved (as was I, as an IBM employee), but only as one of the cooperators. So, at that time, all of our tools were distributed free by the SHARE organization or bundled with IBM’s hardware. By the late 1960’s, a successful legal challenge was mounted against the con- cept of bundled software—led by Marty Goetz at ADR, one of my coauthors in the MetaCOBOL effort. The challenge made software available for sale (or rent), but initially left the hardware manufacturers largely in control of the programming tools business. In the 1980’s, PCs changed all that by democratizing tool-building again, putting it back in the hands of the tool users and enabling real competition among tools. That competition has increased the appeal of tools while lowering their price. That’s why, to old-timers like me, today looks like a utopia of pro- gramming tools.