Schneiderman 1985 Relationship

7/28/2019 Schneiderman 1985 Relationship

1/5

Relationship Betweenand Computer Science

a computer scientist to write sympatheticallyCOBOL is an act bordering on heresy. It requiresbecause academic colleagues and data proc-professionals are both likely to be suspicious ofmotives. Therefore, I feel my first obligation is toe clear my intention and orientation.I believe that COBOL has had a strong and largelyinfluence on the emergence of computerThe development of COBOL was a pioneeringrt that advanced the state of the art in practicalprocessing and language design. COBOL clearlymany flaws, some of which have been overcomerevisions to the original language. Designers ofges have learned from the mistakes andproblems with novel constructs. Thisrs three perspectives on the rise of COBOLchnical, and social/psychological) anddirections for future cooperation.My orientation is as a computer scientist whosework was in database systems and programming.

Based on interviews, reviews of the literature, and personal impressions, theauthor offers historical, technical, and social/psychological perspectives on thefragile relationship between COBOL and computer science. The technicalcontributions of COBOL to programming language design are evaluated. Fiveproposals for computer science research on COBOL and fourth-generationlanguages are described.Categories and Subject Descriptors: 0.3.0 [Genera/]-standards; 0.3.2[Language Classifications]-cosoc K.2 [History of Computing]-coso&software; K.3.2 [Computers and Education] Computer and Information

Science Education-computer science educationGeneral Terms: Design, Languages, Standardization

More recently I have turned my attention to psycho-logical or human-factors issues of programming,database query facilities, and human-computer inter-action (Shneiderman 1980). I have taught introduc-tory PrOgramming coursesin FORTRAN,BASIC,&isCal,COBOL, APL, and PL/~ and have written or coauthoredtextbooks using the first three of these languages.Historical PerspectiveFive aspects of the historical development of COBOLcan be traced as important influences in the alienationof COBOL from the computer science community. First,academic computer scientists did not participate inthe design team. The developers of COBOL were fromthe commercial community: the manufacturers andusers of large data processing systems in industry andgovernment (see the minutes in this issue for lists ofthe participants).

1985 by the American Federation of Information Process ings, Inc. Perm ission to copy without fee all or part of thisis granted provided that the copies are not made or distrib-for direct comm ercial advantage, the AFIPS copyright noticethe title of the publication and its date appear, and notice is

copying is by permission of the American FederationInformation Processing Societie s, Inc. To copy otherwise, or torequires spe cific permission.Department of Computer Science , University ofColleg e Park, MD 20742.1985 AFIPS 0164-l 239/85/040348-352$01 .OO/OO

In 1959-1960 very few academics could have beenclassified as computer scientists, of course, and few ofthem could have made useful contributions, but en-gaging them might have been beneficial.The developers of the Ada language realized thispossibility and made ambitious and successful effortsto elicit the participation of academic and industrialresearchers. Computer scientists can do more thancontribute ideas; they are often effective in dissemi-nating new concepts through their publishing, teach-ing, and lecturing efforts.

. Annals of the History of Computing, Volume 7, Number 4, October 1985


2/5

The second historical aspect is that the COBOLhad little interest in the aca-c or scientific aspects of their work. The Mayissue of the Communications of the ACM wasto 13 papers describing COBOL and relatedEvery article was written by an industry orperson. These people did not have thec frame of mind that involves referencingand related work; only four of the papers hadreferences. Sociologists of science who use cita-to trace the flow of ideas would recognize thisas an indicator of intellectual separatism.

science. It is not surprising that they worked sepa-rately and in parallel. The development of computerscience and data processing might have been substan-tially altered if these communities had taken the timeto meet and work together.

Technical Perspective

The third aspect is the decision of the COBOL de-not to use the Backus-Naur Form (sometimesal Form) notation as the metalan-COBOL. The COBOL developers wereof this work, which appeared in a conference

in June 1959. I dont see the failure to use BNFcentral, but apparently the criticism at the times severe (Sammet 1981, p. 233). The COBOL style ofge has become widely used and might beas an important contribution.

Getting convergence on the technical successes andfailures of COBOL was a difficult task. I spoke to 30-40 computer scientists and data processing profession-als in trying to sort out the issues. The followinganalysis is my own view guided by the interviews.First the successes. The strongest point of agree-ment was that COBOL contributed the record structure,explicit file structure definition, and the separation ofdata definition from procedural aspects. The COBOLrecord and file structure certainly influenced the de-sign of PL/~ and Pascal. The notion of an aggregationof dissimilar items is a major advance over the FOR-TRAN array. The Pascal notion of variant records canbe traced to the COBOL REDEFINES clause.A fourth concern is the process of describing COBOLthe academic and industrial community. Profes-could learn the language from programmerence manuals, but a well-written book emphasiz-the conceptual foundations of COBOL would haven an asset. It took a few years before successful

were available (McCracken 1963; SaxonCOBOL to novices. Note the contrastth the dissemination of Pascal. Niklaus Wirth pub-precise description of the language in Acta(1971), an interesting book titled System-Programming: An Introduction (1973), the widelyPascal User Manual and Report (1975), and aAlgorithms + Data Struc-(1976).

Explicit file structure definitions that included ahierarchy of names for fields and the separate DATADivision were the predecessors of the database man-agement system (DBMS) concept. DBMSs are a vitalpart of computer science and are the source of a richtheory that is still developing rapidly.

A search of the Library of Congress SCORPIO systemd 252 books indexed under COBOL, 529 underand 1054 under BASIC, demonstrating thelower rate of publication on COBOL. Pascalmore recent, but already 208 books are indexedthat programming language.

Another contribution was the diverse set of controlstructures, which were quite sophisticated for the time.The COBOL IF-THEN-ELSE, in spite of its awkwardscope delimiter rules, reduced the need for GOTOS andpermitted the creation of more comprehensible code.The variety of PERFORM statements allowed conveni-ent and powerful looping and some degree of modulardesign. The ease with which paragraphs could becreated, named, and used facilitated hierarchical de-sign.

The fifth historical aspect is that the people whoht have accepted the title of computer scientist inwere not interested in the problem domain ofprograms. The commercial file-processingms were remote from the concerns of computers, who generally dealt with numerical analy-physics, engineering problems, and systems pro-

A popular feature of COBOL that has appeared inother languages is the COPY statement. By includinggroups of statements from a library, organizationalstandards were easily enforced, programmers wereencouraged to cooperate, and reuse of code becameconvenient.Another interesting COBOL concept is the ENVIRON-MENT Division, which allowed users to specifymachine or compiler dependencies. It permitted deli-nition of separate host and target computers, thusforeshadowing the idea of cross-compilers.

In summary, the people and the problems in theworld were very different from the people andems who were laying the basis for computer

Finally, the COBOL community demonstrated thepower of portability and standardization. In spite ofsome local variations, COBOL is largely machine inde-pendent. Programmers could successfully transfertheir knowledge and often their programs from one

Annals of the History of Computing, Volume 7, Number 4, October 1985 l 349

6. Shneiderman - COBOL and Computer Science


3/5

Shneiderman * COBOL and Computer Science

to another. Standardization also encour-the development of software tools and reuse ofSome of the perceived technical failures of COBOLt have been avoided by early consultation withscientists, but other problems would notbeen recognized until the early 1970s. The mosts omission is a function or procedure definitionwith parameters and local scope of variables.original version of COBOL has only global vari-therefore a generic subroutine to sum the ele-s of an array, search a string, or print a bar charts not easy to write. Two programmers workinghad to coordinate carefully to ensure thatnot inadvertently both use the same variablee for different values. The lack of protected mod-boundaries also allowed complex and sometimesprogramming techniques. A DEFINE macrore was in the original language description andto be the first such facility in a high-levelit was never implementedwas eventually dropped from the language. Therevision to COBOL included the now-popular CALLfeature, which permitted parameters and run-me creation of procedure names.Computer scientists often complained about the

COBOL statements and the clutter of theonal noise words. The designers of COBOL appar-believed that the English-like statements woulde programs readable by managers or other non-but the semantics of programming areleast as challenging as the syntax. Computer sci-e background emphasized mathematicalion, which is precise and concise, felt that COBOLs too wordy and somehow unscientific.I found and was sympathetic to several complaintsCOBOL control structures. The scope of an IF-is delimited by a period, which is oftenby programmers when reading and even whening programs. It might have been better to havekeyword such as ENDIF. The PERFORM state-contain a list of statements, only thee of a paragraph. Studying a program is trickyhe reader must hunt for the body of thestatement. With short loops, the overheadannoying, and confusion can increase.Poor string-handling facilities were cited by severalle as a major weakness of early COBOL. Movingcopying of strings was convenient, but insertiondeletion of characters inside a string was difficult.e EXAMINE verbandthe TALLYING and REPLACINGwere included in the early COBOL specifica-to facilitate plans to write a COBOL compiler inThe 1974 version of COBOL contained the

somewhat more powerful INSPECT command, plusSTRING and UNSTRING.Several computer scientists complained about thelack of recursion in COBOL, but I think that it hardlywould have made a difference in the use of the lan-guage.Knowledgeable COBOL programmers in my surveyhad other small complaints, but I did not judge themto be vital.Social/Psychological PerspectiveNow we move on to some more speculative areas thatreflect on the fundamental differences between thecomputer science and business data processing com-munities. The rejection of COBOL by most computerscientists is a product of their desire to avoid thebusiness data processing domain, their pursuit ofmathematically oriented theory, and often their lackof knowledge about COBOL.When asked for his comments, one computer sci-entist who is a widely respected expert in program-ming languages boldly replied, Whats COBOL?" Hisworld did not have a place for COBOL. In fact, severalprogramming language texts (e.g., MacLennan 1983)do not include COBOL in the index. Another responded,Its terrible . . . ugly, but had difficulty explainingwhy. I suspect this prejudice emerges from the bias ofmany computer scientists against the problem domainand the wordy, nonmathematical style of COBOL,rather than from any serious consideration of thetechnical weaknesses. Dijkstra (1982) wrote, COBOLcripples the mind, but he was equally harsh on FOR-TRAN (infantile disorder), PL/I (fatal disease),BASIC, and APL. Tompkins (1983) sought to defendCOBOL, and Reid (1983) responded with many legiti-mate criticisms.The bias against the problem domain is stated ex-plicitly in Pratts programming language textbook(1975; 1984), which says that COBOL has an orienta-tion toward business data processing . . . in which theproblems are . . . relatively simple algorithms coupledwith high-volume input-output (e.g. computing thepayroll for a large organization). Anyone who haswritten a serious payroll program would hardly char-acterize it as relatively simple. I believe that com-puter scientists have simply not been exposed to thecomplexity of many business data processing tasks.Computer scientists may also find it difficult to pro-vide elegant theories for the annoying and pervasivecomplexities of many realistic data processing appli-cations and therefore reject them.Tuckers programming language textbook (1977)has this evaluation: We judge COBOL's programming

- Annals of the History of Computing, Volume 7, Number 4, October 1985


4/5

ures as fair and its implementation dependentas poor . . . its overall writing as fair to poor,reading as fair and its data processingas good. . . . [It has] tortuously poor compact-and poor uniformity. Not much to warm theof a COBOL programmer.

Several computer scientists remarked about theCOBOL and that universityssors did not like dealing with current practice,sought to distinguish themselves with novel lan-theory, and an abstract, more mathematicalOne professor commented that he wasto teaching what is used commercially, whileresearcher sneered at the folly of an English-lookingThe desire to be aloof from current practice was atheme and leads me to theTheory Conjecture: Computer scientists like pro-ng language theory, but find fault with anyused language.The Theory Conjecture should be comforting tosupporters because it means that computerwill express displeasure for almost any pro-mming language that is widely used. Since com-scientists desire to be with the state of the art,that is widely used must also be outdated.cial usage lowers academic prestige.A related principle might be expressed as theEgocentricity Conjecture: Computer scientists appre-programming language except the one that theyThe role of a scientist is to innovate, so commentsother peoples work are often in the form of criti-lays the basis for a proposed improvement.

Sammets book on programming languagesd her review of the history of COBOL (1981)er lists of contributions of COBOL that are close to

l Readable language.l Separate data declaration section with rich recordstructure.l Decent control structures.l Machine-independent, portable, standardizedlanguage.l A useful alternative metalanguage.l Creation of a successful and large community ofdata processing programmers.her review, Sammet (1981, p. 239) writes: I per-do not see much language development . . .

B. Shneiderman - COBOL and Computer Science

significantly influenced by COBOL," and goes on tosay, Most computer scientists are simply not inter-estedin COBOL."I do feel that COBOL was a major influence on PL/I,which was designed explicitly to include the popularfeatures of COBOL,FORTRAN, and ALGOL. COBOL alsohad an impact on the use of record structures inlanguages such as Pascal and on the creation ofdatabase management systems.Most important, COBOL greatly facilitated the enor-mous expansion of computer usage in data processing.The demand for programmers and computers bene-fited the entire industry and stimulated further sci-entific advances because there was such a large marketfor new ideas.The Future: A Challenge to Computer ScientistsThe story of COBOL is not over. The continuingchanges to COBOL, refinements in design guidelines,and improvements in teaching strategies mean thatthe COBOL of today looks very different from theCOBOL of 1960. COBOL and the so-called fourth-gen-eration languages will still be around in 25 more years,and maybe computer scientists still have an opportu-nity to influence their evolution.Let me propose five areas of beneficial COBOL andfourth-generation language research that might be ofinterest to computer scientists.

Code Optimization: There is a grand opportunity toapply traditional compiler optimization techniques toCOBOL. Even more provocative would be to exploreoptimizations that are specific to the COBOL domain.Instead of eliminating redundant mathematical sub-expressions, the COBOL compiler writers could concen-trate on eliminating redundant MOVE or file opera-tions. Global dataflow analysis would be a challengein the COBOL context.

Formal Semantics: Precise descriptions of COBOLsyntax are available, but there are variations in thesemantics of some operations across implementations.Creating a formal semantic description of COBOLwould be useful to implementors and might requirenovel techniques that could be applied in many pro-gramming language situations.Maintenance Tools: The enormous and valuable li-braries of COBOL programs are underutilized becausetools are not adequate for indexing, searching, inter-

preting, and modifying this code. Library-science andexpert-system concepts might be applied to makingthe voluminous literature of COBOL more readilyavailable for reuse.

Annals of the History of Computing, Volume 7, Number 4, October 1985 l 351


5/5

Shneiderman * COBOL and Computer Science

Programming-Style Research: Because COBOL is soused, we would see a substantial benefit iftested style guidelines were available.names, nesting of control structures, use ofpage formatting, modular design,techniques, data structure design, etc.studies of program composition, compre-, debugging, and modification by professionalwould be valuable in resolving some ofissues and formulating a cognitive model of

Software Engineering: In some ways COBOL is aent language as the target for a compiler oroffer higher-level control structures or dataHow might procedural or data abstractionbe molded to fit the COBOL context? Canentists offer an interesting theory of pre-to parallel the theory of compilers? Doesem design in COBOL have features that are

FORTRAN or Ada?This list is only a starting point. COBOL and fourth-languages present many provocative chal-es to computer scientists. Also, electronic spread-ts such as VisiCalc and Lotus l-2-3 are excitingtions that have yet to be properly acknowledgedscience community.

dition to the people I interviewed, I was greatlyby knowledgeable reviews of early drafts byJohn Gannon, Rick Linger, Danielen, Terrence Pratt, Edward Reid, and JeanMy first consideration of this topic wasted by Hank Tropp and Jean Sammets invi-

tation to give a talk at the 1979 .National ComputerConferences Pioneer Day celebration of the 20th an-niVerSary Of COBOL.

REFERENCESDijkstra, Edsger W. May 1982. How do we tell truths thatmight hurt? ACM SIGPLAN Notices 17, 5, pp. 13-15.Jensen, Kathleen, and Niklaus Wirth. 1975. Pascal UserManual and Report. SecondEdition, New York, Springer-Verlag.MacLennan, Bruce J. 1983.Principles of Programming Lan-guages: Evaluation and Implementation. New York, Holt,Rinehart and Winston.McCracken, Daniel D. 1963.A Guide to COBOL Program-ming. New York, Wiley.Pratt, Terrence W. 1984.Programming Languages: Design

and Implementation. Second Edition, Englewood Cliffs,N.J., Prentice-Hall.Reid, E. October 1983.Fighting the disease:More commentsafter Dijkstra and Tompkins. ACM SIGPLAN Notices 18,10, pp. 16-21.Sammet, Jean E. 1969. Programming Languages: Historyand Fundamentals. EnglewoodCliffs, N.J., Prentice-Hall.Sammet,Jean E. 1981. The Early History of COBOL. InWexelblat, R. (ed.), History o f Programming Languages,New York, Academic Press,pp. 199-243.Saxon, James A. 1963. COBOL. Englewood Cliffs, N.J.,Prentice-Hall.Shneiderman,Ben. 1980.Software Psychology: Human Fac-tors in Computer and Information Systems. Boston, Little,Brown.Tompkins, H. E. April 1983. In defenseof teaching struc-tured COBOL as computer science or, Notes on being sagestruck). ACM SIGPLAN Notices 18, 4, pp. 86-94.Tucker, Allen B. 1977.Programming Languages. Reading,Mass, Addison-Wesley.W&h, Niklaus. 1971. The programming languagePascal.Acta Informatica 1, 1, pp. 35-63.Wirth, Niklaus. 1973.Systematic Programming: An Intro-duction. Englewood Cliffs, N.J., Prentice-Hall.Wirth, Niklaus. 1976.Algorithms + Data Structures = Pro-grams. EnglewoodCliffs, N.J., Prentice-Hall.

* Annals of the History of Computing, Volume 7, Number 4, October 1985

Documents

Schneiderman 1985 Relationship