Book-Reader-Assist/library/The Psychology of Computer Programming/Chapter-11-Programming-Languages/Chapter-11-source-text.md

The Psychology of Computer Programming — Chapter-11: Programming Languages

• Source: /library/The Psychology of Computer Programming/source-file.pdf
• PDF pages: 263–276
• Pages without text: none
• Note: Includes the Silver Anniversary comments that immediately follow the original chapter. Text comes from the scan's OCR layer and may contain recognition errors.

---

PROGRAMMING LANGUAGES it ountless papers have been devoted to the subject of program- ming languages, but the topic of psychology is not easily found in any of them. The most typical attitude about programming languages was expressed by one author who pleaded for an effort “to really attempt to understand what programming and program- ming languages are all about.” Although we all could agree with this laudable sentiment, we might not agree with his explication of what he thought they were “all about,’’ namely, ‘how they related to our mathe- matical foundations on the one hand and to current as well as imagined computing equipment on the other.” In that analysis, there is no mention of people, the poor critters who have to use programming languages, except perhaps for the type of people who spend their time imagining computing equipment—hardly the typical language user! In this chapter, we also shall attempt to understand what programming languages are all about, but our point of view will consider people first 205

206 Programming Tools and machines and mathematics second—and then only as they impinge on the psychological discussion. As we have already, in this book, spent considerable time discussing what “programming” is, it will be appro- priate to begin our study of programming languages by considering what a “language” is, and to what extent programming languages are lan- guages in other senses of the term. With that understanding as a basis, we will attempt to throw some small light on the subject of programming language design. Since most programmers do not have much to say about the design of a language, we shall attempt to satisfy a more uni- versal need by providing principles for selection of a programming lan- guage from among those already designed for us. PROGRAMMING LANGUAGE AND NATURAL LANGUAGES lf there is one area in which every man is an expert, it is language. We all speak a language, and some of us can even read and write the lan- guage we speak. If a foreigner says “I would like of dinner,’’ any of us can correct his erroneous use of the preposition—even those of us who do not know a preposition from a proposition or a prepossession. The typical person’s understanding of the language he uses, however, is not so pro- found as to prevent him from labeling something as a language that might resemble one only superficially. Thus, it is not surprising that the systems of notation which we use to communicate with our computers came to be known as “programming languages.” In fact, the very first programmer, Lady Lovelace, seems to have had the idea of a programming language as a language as early as 1846. Although she was the niece of Lord Byron, it was not her knowledge of poetry but, rather, of mathematics which led her to think of a symbolic system as a language—for the idea of mathematics as a language seems to go back into the misty ages of the past. Thus, the idea of “programming language” was really born with the idea of programming itself. In view of the venerable past of the programming language concept, it would be pedantic to attempt to demonstrate that programming languages are not “real” languages. Languages are what they say they are, and we are perfectly entitled to include systems of communications between man and computer under the same rubric as systems of communication be- tween man and man or beast and beast. What might be possible, however, is to inquire about possible differences between computer languages and the other kinds. One possible point of departure for comparing the two types of lan- guage is the list of ‘design features’ which Hockett has given for the

Programming Languages 207 natural language of human beings (speech). The first of thirteen features which he lists is the use of a “vocal-auditory channel’’—that is, | speak and you listen. The use of this channel has several advantages, particu- larly the freeing of the hands and other organs for separate activities. Programming is generally a manual operation—we laugh when someone asks us to “say something in FORTRAN.” It is a written language, and in spite of its resemblance to other written languages, it differs from them in not having a speech system behind it. Not that written languages are simple transcriptions of speech, not at all; but a written language such as English is strongly influenced by its relationship to a spoken language. This influence is not so strong in other written languages, such as those using the Chinese writing system, but the influence—the mutual influence —always exists. One effect of not having a spoken form of a programming language is a possible slowing down of language innovations, for the spoken form of the natural language is most often the source of new language forms. Another effect is the difficulty with which we can talk about a program- ming language without a blackboard or pencil and paper. Every program- ming office should have a blackboard, chalk, and many erasers. The second of Hockett’s features is “rapid fading.” We need many erasers because what we “say” about a program on the blackboard does not erase itself the way an utterance does. Sometimes it is a convenience to have rapid fading in a programming language. Once, when installing a computer in Bermuda, we fell into the habit of sketching our rough programming ideas in that portion of the coral sand between the apogee and perigee of the wash of waves. The ocean saw to it that each idea lasted only about as long as it was worth; but in ordinary programming work, we usually have to make explicit provision for getting rid of our obsolete listings, unless we have a graphic terminal. The third feature is ‘‘broadcast transmission and directional reception,”’ which means that we speak more or less in all directions at once, but we can detect, when listening, from what direction the speech is coming. Programming, of course, is quite the opposite. Programming shares with prayer the feature of directional transmission and broadcast reception. Heaven receives prayers, and the computer receives programs, from all over at once. We might imagine, then, that what variation is permitted in programming languages would be on the way out of the computer, but just the opposite is true. In spite of the diversity of its listeners, the “system” simply broadcasts identical messages to all of them. Certain possibilities for change lie here. Probably the really important difference between programming lan- guages (of today) and natural languages lies in Hockett’s fourth design feature—interchangeability. Although we often listen to people whom we

208 Programming Tools cannot understand, or often speak to people who cannot understand us, the normal image of human speech communication is that each partici- pant can reproduce any linguistic communication he can understand. In short, we “talk the same language.’”’ When we talk to our computers, unhappily, we are usually speaking in different tongues. Here, at least, for all their other faults, the machine languages have the upper hand, for at least a dump looks a little like the stuff we put into the blasted machine. Not so—not nearly so—when what we put in was FORTRAN or COBOL. How truly sad it is that just at the very moment when the com- puter has something important to tell us, it starts speaking gibberish. There is, fortunately, a trend today to try to introduce interchangeability into the dialogue between man and machine through a programming language, and this step is bound to have important psychological effects on programming effectiveness, even though it may decrease machine “efficiency.” But there is another kind of noninterchangeability which is perhaps even more severe and yet less subject to mechanical remedies. Programs are used not only for man-machine communication, but for man- man communication as well. Yet communication in programming lan- guages does not seem to have the interchangeability we take for granted in natural language communication, even between the same two people. At the extreme of this problem is the case of the man who can read COBOL programs but cannot write them. Probably, he cannot discuss them, either, which makes for most difficult communication problems if he is, say, a programming manager. In Hockett’s remaining design features, programming languages do seem to measure up to natural languages—actually going beyond them in the exhibition of such features as productivity, the ability to express something that has never been expressed before. In a way, the design of programming languages reflects different patterns of use than are com- monly found in natural language. To be sure, it is important that a natural language be productive, in the above sense, but for a programming lan- guage, productivity is the sine qua non. When we consider function of a language, rather than the design fea- tures which realize function, the deepest differences between program- ming languages and natural languages emerge. Bruner gives six general functions of natural language—emotive, connotative, referential, meta- lingual, poetic, and phatic. Although we can identify each of these in programming languages, their relative importance and frequency of use is quite different. Emotive language consists of utterances such as “‘How do you do?” and “Fiddlesticks!,” which are ritualized expressions of the emotional state of the speaker. Generally speaking, the computer is not interested in the emotional state of the programmer, although evidences of it may creep

Pregramming Languages 209 into his program. Phatic language consists of utterances such as “Uh hu... but...and...,”’ which serve the function of keeping the channel of communication open or testing its state of operation. An exact counter- part of the phatic “and” is found in some terminal systems where the user can keep his program from being pushed down in the priority stack by fiddling with the shift key while he is thinking. Without the shifting, the computer would fail to get a communication for a long period and assume that the user’s program could safely be put in a more passive state. Of course, jiggling the shift key defeats the purpose of the scheduling algo- rithm, but more important than that is the interference it probably causes with the programmer’s thought processes. Hopefully, such phatic com- munication can be removed from the already cluttered field of program- ming language phenomena. At first blush, poetic language would seem to have no place in pro- gramming, yet it plays a role which should be increasingly recognized. In poetic language, the patterning of the language itself—for esthetic reasons—is uppermost. But what, in programming, is there to correspond to Keats’ lines such as these? O Attic shape! Fair attitude! with brede Of marble men and maidens overwrought, With forest branches and the trodden weed; Thou, silent form, dost tease us out of thought... lf we mean to read aloud, the answer is nothing, for we have already seen that programming language is not speech, let alone song. But is there not, indeed, something in form for form’s sake which “dost tease us out of thought’? A programmer would not really be a programmer who did not at some time consider his program as an esthetic object. This part is not quite symmetrical; that part is clumsy and doesn’t flow in an appropriate man- ner; the whole thing does not look proper on the page. To be sure, it is fashionable among programmers to be rough and tough and pragmatic, but deep down each programmer knows that it is not enough for a pro- gram just to work—it has to be “right’’ in other ways. Later, when we discuss language design and program testing, we shall see that the cor- relation between the esthetic and the pragmatic value of a program is not accidental—the more pleasing to the eye and mind, the more likely to be correct. Or, put more poetically, ‘Beauty is truth, truth beauty.”’ The prose of programming consists largely of referential and connota- tive parts. Referential statements are statements or questions of fact— “That is Heidi,” “This is a fixed-point binary number with 13 bits and a sign.” Connotative statements give instructions—‘‘Stop pulling my leg,”

210 Programming Tools “Find the inverse of this matrix.’”’ Of these types, we shall say more later. But here we should note that, although both are common in natural and programming languages, the universe of discourse is much, much smaller in programming. Thus, even though there is essentially no limit to the number of assignment statements or declarations in PL/I, the number of possible utterances in English is enormously greater. We are aware of the importance of the size of the universe of discourse in programming languages, but it is probably most important for their psychology, as we hope to show. Metalingual utterances—talking about language—are of primary im- portance in programming, especially in the learning process, when pro- gramming such things as compilers, and when designing and defining programming languages. Until recently, programming languages differed from natural languages in that they relied exclusively on natural language as a metalanguage—with the possible use of a little mathematics. This chapter, for example, is one long metalingual statement about program- ming languages, completely couched in English. Now, however, increas- ing attention is being turned to special formal or informal languages de- signed to facilitate metalingual expression and reasoning. Moreover, cer- tain programming languages are beginning to incorporate metalingual features of great power—giving us the ability not only to manipulate programming languages but to manipulate assertions about programming languages. Although the future of these efforts is not clear, and empirical evidence is almost entirely lacking, we hope to be able to give some hints of the role which metalingual features can play in the psychology of programming languages. PROGRAMMING LANGUAGE DESIGN It is impossible to begin a discussion of psychological principles of programming language design without recalling the story of “Levine the Genius Tailor.”” It seems that a man had gone to Levine to have a suit made cheaply, but when the suit was finished and he went to try it on, it didn’t fit him at all. ‘“‘Look,” he said, ‘‘the jacket is much too big in back.” “No problem,” replied Levine, showing him how to hunch over his back to take up the slack in the jacket. “But then what about the right arm? It’s three inches too long.”’ “No problem,” Levine repeated, demonstrating how, by leaning to one side and stretching out his right arm, the sleeve could be made to fit. “And what about these pants? The left leg is too short.” “No problem,” said Levine for the third time, and proceeded to teach

Programming Languages 211 him how to pull up his leg at the hip so that, though he limped badly, the suit appeared to fit. Having no more complaints, the man set off hobbling down the street, feeling slightly duped by Levine. Before he went two blocks, he was stopped by a stranger who said, ‘| beg your pardon, but is that a new suit you’re wearing?” The man was a little pleased that someone had noticed his suit, so he took no offense. “Yes it is,” he replied. “Why do you ask?” “Well, I'm in the market for a new suit myself. Who’s your tailor?” “It's Levine—right down the street.” “Well, thanks very much,” said the stranger, hurrying off. ‘I do believe ’ll go to Levine for my suit. Why, he must be a genius to fit a cripple like you!” Would it be inappropriate to concoct a version of this story called “Levine the Genius Language Designer’? The first problem in discussing language design is that we do not know the answer to that question. We do not know whether the language designers are geniuses, or we or- dinary programmers are cripples. Generally speaking, we only know how bad our present programming language is when we finally overcome the psychological barriers and learn a new one. Our standards, in other words, are shifting ones—a fact that has to be taken into full consideration in programming language design. Why are our standards so flexible in this matter when they are all too often rigid in others? The problem lies in the rigidity of our machines and, through them, in the rigidity of our programming languages. When- ever a man is confronted with a new machine, he is forced to choose be- tween making some adjustments himself or adjusting the machine to narrow the gap between what is desired and what exists. Although ma- chines, and especially computers, are adjustable, the time scale for them to be changed is generally much longer than for a person. Pro- gramming languages are attempts to adjust the raw computer to better fit human propensities and limitations, but they too suffer from a long update cycle. Thus, the user is faced with the choice of waiting for months or years while he develops his own programming language—a primrose path which many a man has trod—or gritting his teeth and learning to live with what he has. Humanists often contend that machines tend to dehumanize people by forcing them to have rigid personalities, but really, the contrary is true. Because the machines are rigid, the people who use them must— if they are to be successful—supply more than their share of flexibility. Perhaps this is the effect that the humanists are describing as ‘““dehuman- ization,” for in ordinary human intercourse, each party gives and takes

212 Programming Tools his share. Relationships in which one party does all the giving or all the taking are not fully human, and tend to produce personality distortions in one or the other. In making our adjustments to our particular programming language, we can easily become attached to it simply because we now have so much invested in it. We often listen to a man complaining about his nagging, slovenly, and prodigal wife, only to find that when asked why he doesn’t leave her, he replies that he cannot live without her. Most people would prefer almost any amount of pain to giving up the familiarity of some constant companion for an unknown quantity. We see this effect when we try to teach a programmer his second language. Teaching the first is no great problem, for he has no investment in any other. By the time he has learned two or more, he is aware that more things exist in this world than he has dreamed of. But letting go of the first is, to him, just a promise of pain with no promise of compensating pleasure. Perhaps this situation could be improved if we could enunciate and teach certain principles that are not tied to particular languages, so that even the beginner would have some less relative measure to hold up against the language he is learning. But teaching practice today in our universities and programming schools seems to be pointing in exactly the opposite direction. Instead of trying to teach principles, or at least trying to teach two contrasting programming languages simultaneously, or at the very least trying to teach one programming language which rather broadly represents the major possibilities, the schools seem de- voted to teaching how to program in a single simple and artificial lan- guage. The objective seems to be to get the student writing some kind of program as soon as possible—a not unworthy aim—but at the expense of limiting the future growth of the programmer. To be fair, we should recall our distinction between the professional and amateur. The schools, it seems, are devoting themselves primarily to turning out vast quantities of amateurs—perhaps under the assumption that the professionals can and should take care of themselves. But when the language designers begin to believe that the principles underlying the design of an amateur’s language are the same as those upon which a professional’s are based, then we have trouble. In order to get at the principles underlying the design of programming languages to fit psychological realities, we shall have to get down to fundamental empirical data. Reading programs will be a help, but reading is not enough. When we read a program, we can seldom tell with cer- tainty why a particular piece of coding is present. To understand the psychology of programming languages, we shall have to do more than read programs—we shall have to observe programs being made. Even

Programming Languages 213 this process—even interviewing programmers—will not tell us all we want to know, and we shall have to resort to many sources and devices to get even a slightly better picture than we have by intuition. One reason for these complexities is that the programmer himself seldom knows why he does what he does—which is a general problem in the study of any human behavior. Consider, for example, the following situation. A programmer writing in FORTRAN wants to use a subscript expression such as (J-21). He knows that there are rules—perfectly explicit and unambiguous—about which subscript expressions are permitted and which are not. But he is not quite sure of the rule as it applies to this case, so what does he do? Well, he might look up the rule in his manual, but if he is a clever fellow, he will probably just make a preliminary calculation by such a statement as K — J-21 He is sure that K is an acceptable subscript, and this is much faster than looking up the rule. It may—to be sure—be slower in the program, but that is not the question uppermost in his mind at this moment.. Now, why did the programmer do this? Because of a limitation in the FORTRAN language? But, you might argue, J-21 is not prohibited by FORTRAN, so it must be a limitation of the programmer—of his under- standing of FORTRAN. Although this argument places the blame, it mis- leads us in designing or evaluating a programming language, for would it not be also correct to say that in PL/I, the programmer would have been much less likely to make this error? Why? Because he would be more likely to know that there were no restrictions on subscripts in PL/I, so it would not even occur to him to worry about whether a par- ticular expression was permitted or not. When we assess a programming language, or a machine, from a psy- chological point of view, we cannot grant ourselves the luxury of putting all the burden of poor programming on the poor programmer. If the same programmers get consistently better results using language A than using language B, what good are arguments that they would have done better in language B, if only they had been smart enough to master it. Of course, there is a time dimension to this argument, for one must learn to use a programming language or a machine. Thus, the evaluation of these things depends on the entire system comprising the courses, teaching materials, language, compiler hints, programming assistance and anything else, which may lead to one language being better used than another. Perhaps the messages coming from the terminal when an error is made are more motivating in one system than another. Perhaps the programmer feels he is more important if he is chosen to program

214 Programming Tools in machine language instead of FORTRAN. If we are to be effective in improving the quality of languages, we shall not be able to dismiss any such factor out of hand. In a way, the reason it is so hard to attribute the source of program- ming inefficiency to either programmer or programming language is that if we had ideal programmers, programming languages would not be necessary. It is a psychological difficulty which prevents us from writing our problem specifications directly in machine language. Let’s face up to it: people don’t think the same way that computers do—that’s why we use computers. Programming is at best a communication between two alien species, and programming languages with all their systems paraphernalia are an attempt to make the communication simpler for one of those species. Which one? Not the computer, certainly, for nobody ever heard a complaint from a computer that it couldn’t do the work. SUMMARY The use of the term “language” in the phrase “programming language”’ is in many ways damaging to progress in communication between man and machine. Just calling it a language doesn’t make it one, and may instead lead to false analogies which, in turn, lead to misguided research efforts. To make progress in programming languages, we must first give up the holy grail of trying to program in a “real” language, for program- ming languages can never be the same as human speech. We may then transfer our quest to making programming languages more ‘‘natural,’’ not in the sense of being identical to English or some other culture’s con- tribution to the Tower of Babel, but in the sense of a consonance be- tween the mode of expression and the mind of the expressor. But in the end, to get a good ‘“‘fit,”” perhaps the customer will have to scrunch over a little—perhaps we are ultimately going to have to change our ways of thinking to fit our computers. Why not? Hasn’t every other human in- vention changed man? QUESTIONS For Managers

1. Are chalkboards standard equipment in your programming offices? Have you ever turned down a request for a chalkboard?
2. How were the programming languages used in your shop chosen?
3. Relate any experiences you have had with a change in programming languages in your shop.

Programming Languages 215 For Programmers

1. Is the person who designed your language a genius? Give some ex- amples of his genius, from your own experience.
2. Relate your experiences in learning your first and second and third programming languages, trying to point out psychological differences in the experiences based not so much on the languages themselves but on the order you learned them.
3. If you are an experienced FORTRAN programmer, can you give the precise rules for subscript expressions? Are you sure? How does it influence your programming when you are not sure of a rule? Do you look it up?
4. Has being a programmer changed the way you think when you are not programming? If so, give some examples. BIBLIOGRAPHY Morrison, Phillip, and Emily, eds., Charles Babbage and His Calculating Engines, New York, Dover Publications, 1961. Along with Babbage’s writings on his machines, we find Lady Lovelace’s com- ments, which show a clear understanding of many of the fundamental principles of programming languages. Those who believe that the progress of knowledge is monotonic and increasing should read this book carefully. What happened, they should ask, to this understanding between the years 1860 and 1940? Perhaps because Babbage was unable to separate clearly the principles of his machine from their mechanical embodiment, his works lay scattered and forgotten in li- braries all over the world, only to be rediscovered after his inventions had been reinvented in an electric and electronic embodiment. Is there a lesson here, too, about programming languages? Zemanek, H., Semiotics and Programming Languages, Communications of the ACM, 9, No. 3 (March 1966), pp. 139-43. Zemanek was the head of the IBM Vienna Laboratory while it was developing the Universal Language Document for PL/I, probably the most ambitious metapro- gramming document ever attempted—and probably the most successful. This article gives some of the structure of his thought, which clearly influenced the course of the ULD development. Greenberg, Joseph H., Universals of Language, 2nd ed., Cambridge, Mass., M.I.T. Press, 1966. Based on, but not a verbatim account of, a 1961 conference, this book gives a good introduction to the search for universal features of languages. In addition to Hockett’s paper, it contains at least six other papers that should be of interest to programming language designers, although, of course, programming languages are not considered languages by these linguists. Bruner, Jerome, Toward a Theory of Instruction, Cambridge, Mass., Belknap Press of Harvard University, 1966. Bruner gives his six general functions of language, along with many other thoughts.

216 Programming Tools Bruner is one of the most important modern thinkers and researchers in the areas of language, learning, and thought, and this book is a good introduction to his ideas. Miller, George A., Language and Communication, revised ed., New York, McGraw- Hill, 1963. No programming language designer should be permitted to design another lan- guage until he has read this book. As Miller says in his introduction: “A scientific study of language, as opposed to a speculative discussion, begins with direct observations of communicating individuals and searches for the relation of these observations to the existing body of scientific knowledge.” Vygotsky, Lev Semenovich, Thought and Language, Cambridge, Mass., M.!.T. Press, 1962. The translation of the work by the great but short-lived Russian psychologist re- mains today probably the most stimulating and readable work on the relationship between thought and language. No programmer could fail to profit from reading this book. Steel, T. B., Jr., ed., Formal Language Description Languages for Computer Pro- gramming, Amsterdam, North-Holland Publishing Co., 1966. These papers are the proceedings of an IFIP working conference on formal lan- guage description languages—that is, on formal metalanguages for programming languages. Although uneven, it is a rich mine of conceptual nuggets for those in- terested in the language of language, or the language of language of language, Orierrs Symposium on Extendible Languages, Sigplan Notices, 4, No. 8, Association for Computing Machinery, New York, 1969. Extendible, or extensible, programming languages are languages in which the language itself can be manipulated by the programmer, This symposium fairly well represents the state-of-the-art at the time it was published. Sammett, J. E., The Use of English as a Programming Language, Communications of the ACM, 9, 3 (March 1966), pp. 228-30. Higman, Bryan, A Comparative Study of Programming Languages, Section 15.3: Subsets of English, New York, American Elsevier, 1967. Two essays to discourage those who think that the answer to all our problems is to program in a “real” language.

Silver Anniversary Notes x, Pi Comments on Chapter 11: Programming Languages Over the years, programming languages have in some ways become more “natural,” yet, at the same time, we finally seem to have given up the rather ridiculous idea of programming in “natural language.” The change has been two-way, as many terms and concepts from programming have crept into use in our natural language. For example, even as dumps have become rare in soft- ware development, the term “memory dump” has become a way of describing a boring monologue. We've all learned things in twenty-five years, but we may not have noticed learning most of them. When | reread my words on the lack of a “vocal-auditory” channel for programming languages (p. 207), | realized that at the time | wrote the section | had never worked with blind programmers—people who use the vocal-auditory programming language all the time. Alas, at the same time the vocal-auditory channel is improving for blind programmers, programming lan- guages are taking a turn for the visual—which enormously complicates the blind programmer’s life. The details change, but the principle remains the same: What is a good language for one person is anathema for another. Object-oriented (OO) languages provide a case in point. Although many OO enthusiasts don’t realize it, the first OO language existed more than twenty-five years ago. Of course, you wouldn’t know it from the first edition of Psychology, because | didn’t include material on the subject. Back then, | didn’t think the OO ideas would ever be important for general-purpose programming. | had worked

Silver Anniversary Notes with Simula’s creators in Oslo in 1968 and was a Simula enthusiast myself, but | saw the language’s features through the eyes of a simulation developer, not a language developer. At the time, | failed to realize Simula’s potential—partly because | noticed how few of my students seemed able to master the new way of thinking. Even today, many programmers just don’t grasp the object-oriented paradigm, although this situation may change as better teachers than | take over. Even though technology has changed, some things haven’t changed at all. Though whiteboards have replaced chalkboards, they serve the same essential function (and still aren’t erased frequently enough). Though the penance for syntactic “sin” (syn?) is less severe in these days of personal computers, pro- grammers still pray to their machines. Though the level of languages has gener- ally been raised a notch or two, we still have to resort to hex gibberish when things really start to go wrong. And, to take a final example, “Levine the Genius Tailor’ (or “Genius Language Designer’) remains a favorite story among my readers. We still don’t know “whether the language designers are geniuses, or we ordinary programmers are cripples” (p. 211).