The Community for Technology Leaders
RSS Icon
Subscribe
Issue No.10 - October (2006 vol.39)
pp: 7-9
Published by the IEEE Computer Society
David Alan Grier , George Washington University
ABSTRACT
We've learned a great deal about computer languages and language design in the past decades.
There was a time when computer manufacturers made house calls. The technical representatives who traveled to customer sites upgraded operating systems, fixed software bugs, trained personnel, and generally assisted the computer managers. They carried a full set of manuals in the trunks of their cars and used gas station pay phones to communicate with their offices.
During the period I worked as a tech rep, I would gather with the other reps in the company cafeteria each morning to get my day's assignment. We sat at long tables, sipping coffee and sharing gossip, dressed in that odd combination of high business fashion and crepe-soled shoes. We spent much of our days driving from site to site. Yet, we knew as much about our customers and our company as if we'd been connected by a high-speed data network.
Routine Problems
My partners, Steve and Lisa, were in their early thirties. An expert on operating systems, Steve could diagnose problems without referring to the reference manuals buried under layers of soda cans and windsurfing paraphernalia in his trunk. Lisa was skilled at reading memory dumps, the snapshot of memory that spewed from the printer at the moment the computer failed. She approached the task in a set routine. Clutching a highlighter in one hand and a pen in the other, she worked through the pages of symbols, annotating the job table, coloring the file headers, and circling any bit of code that seemed out of place.
On most mornings, our list of customer problems was fairly routine: an auto parts distributor that had forgotten how to reboot its machine, a county courthouse that was having trouble with the sort package, a labor union that couldn't clear enough space on its hard disk. While traveling from site to site, our conversation would usually slide toward Lisa's impending wedding, which was scheduled for the fall. She'd known her fiancé for 10 or 11 years but was coming to doubt her commitment to the marriage.
"The more I learn about him," she complained, "the more I wonder what will be left for the marriage."
Though Lisa freely shared the details of her love life, she didn't like to be questioned. Should Steve or I suggest that she might want to rethink her plans, she would immediately interrupt. "It will work out," she'd say more to herself than to us. "I'm sure that it will work out. We will learn how to make it work." She ended the conversation with the unanswerable retort, "You're guys. What do you know?"
A Tough Assignment
In midsummer, we were assigned a problem from a hospital on the edge of town. The facility had pretensions of becoming a major medical center, the Mayo Clinic of the area. It had built a modern complex and renamed itself after a famous 19th-century biologist who had described the operation of the digestive system through a series of ethically questionable experiments.
"What's the problem?" I asked as we drove to the hospital's computer center.
"We made a promise in the heat of passion," replied Lisa, "and hoped that they would forget the commitment when the morning came."
The hospital was operating an early network, a set of small computers that were connected to a mainframe. Their technical staff claimed that the network was too slow. Our salesmen claimed that it operated as specified in the contract. Lacking any concrete evidence for either claim, all we could do was argue.
For the better part of the morning, Steve and Lisa battled with the hospital managers. Each side talked around the problem, hoping to find an argument that would catch the others off guard. When the end of the meeting approached and no agreement was in sight, all parties decided that we needed a program that would monitor network operations, that I would write this program, and that I would write it in Cobol.
"Why Cobol?" I asked when we got into the car. "I don't know Cobol."
"They only had enough money to buy the engagement ring," said Lisa in her most strident voice. "They never bought a full set of compilers."
"I'll have to use the exponential function," I protested. "Cobol doesn't even have an exponential function." I wasn't certain of this last fact, but I thought it was unlikely for a business language to have the full set of higher mathematical functions.
"Listen, number boy," said a weary Steve from behind the wheel. "If we ever want to drive away from this hospital and never think of them again, they're going to have to show us theirs and we're going to have to show them ours." In case I hadn't understood, he added, "They're going to want to see how we gather the data and they don't know anything but Cobol."
With that conversation, all debate was over. The time had come for me to start the program.
The next morning, instead of going on the road with Steve and Lisa, I sat down at a computer terminal in the tech rep office, put the Cobol manual on my lap, and started pecking away. I needed a couple of hours to write a simple program and more time than I'm willing to admit to complete the code that gathered the network data.
Oddly, I found that it wasn't that hard to compute an approximation to the exponential function using arithmetic designed for dollars and cents. I just needed to remember that e 1 equaled "0.37" not "$.37."
Lisa reviewed the program after my second or third day of effort. "Did anyone tell you that you write Cobol like a PL/I programmer?" she asked.
"But I don't know PL/I," I protested.
"Even better," she said. "You write Cobol like an ignorant PL/I programmer."
Before I finished the code, I received comments not only from Steve and Lisa but also from our boss and the regional manager. In our world, programming wasn't a solitary activity. You didn't write programs to please yourself. If you put an idea into signs and symbols, you had to be ready for comment and criticism.
Languages with a Purpose
Even at the time, Cobol, the Common Business-Oriented Language, was hardly the most fashionable tool for exploring the operations of a computer. It was language for accounting systems and inventory databases. To write a network monitor in Cobol was roughly the equivalent of writing a modern newspaper story in Chaucerian English.
Cobol had its origins in the period when languages were tightly identified with a purpose. Fortran (1957) was the scientific language. Algol (1958/60) was for algorithms and systems. LISP (1959) was for research in artificial intelligence. Cobol (1959) was the language for business. The story of these languages is the story of how computer projects become public property, their development guided by open discussion and criticism.
A private Fortran
The oldest language, Fortran began life as a proprietary IBM project. The company assembled a half-dozen programmers and installed the team in an office near IBM's Manhattan headquarters. During its first years of operation, the Fortran group didn't have much contact with anyone outside IBM or even with other IBM programmers. They were located on the 16th floor and had to take an elevator to reach the computer room.
The Fortran team didn't have many models to follow. We "simply made up the language as we went along," recalled John Backus, the group's leader. Also, they weren't inclined to pay attention to other ideas about programming languages. "It was typical of the unscholarly attitude of most programmers then," Backus wrote, "that we did not bother to carefully review the sketchy translation of [other] proposals that we finally obtained" for language features. Only as they prepared for Fortran's first release did Backus and the others show the code to programmers at two large IBM sites: United Aircraft and General Electric.
A public Algol
The Algol project, which started shortly after the first release of Fortran, was a much more public activity. A larger project, it involved researchers from two committees, one based in the US and the other in Switzerland. These committees actively circulated proposals for the language syntax and solicited comments.
Their second proposal, released in 1960, received a great deal of attention because it described the language with an algebraic form now known as the Backus-Naur form. Often called "Algol lawyers," these researchers spent hours studying the descriptions of the language, identifying inconsistencies, and flagging ambiguities. One pair of critics claimed that some parts of the syntax were "so subtle that Algol translators cannot be trusted to handle them correctly."
A fiercely debated Cobol
Cobol was a large, transparent project from its inception. Every aspect of its design drew comments from vendors, users, and academic computer scientists. The language's goals were drafted at a May 1959 conference sponsored by the US Department of Defense. These goals were published with a minority report that criticized almost every conference decision, including one that seemed obvious to many in attendance: the idea of using English as the basis for the new programming language. The "English language is not a panacea," argued the critics, "as it cannot be manipulated as algebraic expressions can."
The design for Cobol developed over the summer and early fall. Most of the syntax was debated in public meetings, where individuals were free to share their ideas. Still, both users and vendors criticized the final specifications when they were published that November. One Cobol designer among the critics ultimately removed his name from the report. He pointed to aspects of the language that were "major deficiencies which reduce its effectiveness as a common language."
In the four decades since Cobol's release, we've learned a great deal about computer languages and language design. We have a collection of theoretical tools, derived from formal language theory, that help us create good designs. We also now have a long history of debate over language design and standards.
Java's Baptism
Java, one of the more important languages of the past 15 years, illustrates how a new language engages the public. Like Fortran 40 years before, Java was the product of private industry. Its Sun Microsystems design team wanted to create a language that would work across the Internet and operate with new Web browsers, such as Mosaic. The Sun designers built upon ideas that had been publicly tested: the C and C++ languages, the concepts of distributed processing, and the elements of object-oriented programming.
While Algol was debated in the pages of scholarly journals and Cobol was critiqued at committee meetings, Java received its critical baptism over the Internet. In March 1995, Sun posted the source for Java online. Within two months, the compiler had drawn the attention of system developers, academic programmers, and the merely curious.
As the complier began to find an audience, e-mail started flowing into Sun's offices. "At first it was maybe 20 e-mails a day," recalled one Java developer. Then it became hundreds and eventually thousands. Some were questions. Some identified bugs. Some commented on the language design.
Initially, the Java designers were able to answer each e-mail. However, before the summer ended, they'd written a system to send a common reply to every incoming message from the growing community of Java users.
The original Cobol designers would have approved of such a method for engaging a community of users. "[E]xperience with real users and real compliers is separately needed before 'freezing' a set of language specifications," wrote one of the original Cobol committee members in 1981. "Had we known from that beginning that Cobol would have such a long life, I think that many of us would have refused to operate under the time-scale that was handed to us."
Reaching a Compromise
By the time I finished my network analyzer, my work had been a public document for nearly a month. The hospital systems administrator had reviewed the code, section by section, checking ideas that he approved and making notes in the margin. He wrote nothing about my approximation to the exponential function. When he completed his review, we installed the program at the hospital and let it run for a week. I then collected the data summaries and prepared a simple report.
I presented my report to a joint meeting of managers. The hospital staff sat on one side of the table. We were on the other. The meeting quickly became testy because the report exposed the operation of the system for all to see. Our managers were general pleased with the report, for it showed that all but two applications were performing as specified in the contract. One of the programs was running a bit slow, but it's performance was close to the contract specification. However, the final application was performing badly and was an item of contention for all in the room.
The meeting lasted well into the afternoon. We debated every aspect of the troublesome application. What was it doing? Why was it consuming so much memory? Had my program measured it correctly? Three times, they questioned my code, though again, no one commented on my approximation to the exponential function.
In the end, the two sides reached a compromise. The hospital accepted the claim that the network generally met the standards outlined in the contract. Our company conceded that the one application was performing badly and that they'd fix the problem by rewriting the programs or by giving the hospital a little more memory or something like that.
Conclusion
Steve, Lisa, and I resumed our regular rounds of auto part distributors, county courthouses, and union offices. For a time, we were the subject of much discussion at the morning meetings, as no other problem that summer had been so contentious. Then one Monday morning, Lisa arrived at the cafeteria late. She walked in the door with a firm stride and a tense jaw. Her eyes reflected grim determination, as if she merely wanted to get through the day.
"Is everything okay?" Steve asked.
Lisa paused, as if she were debating what she wanted to tell us.
"Yeah," she said.
"Do you want to talk about something?" I asked.
She paused again. The cafeteria was starting to get quiet for the morning meeting. Several pairs of eyes had shifted our way, and an equal number of ears had tuned into our conversation. Lisa glanced around the room and reached a quick conclusion.
"I don't feel like listening to men today," she said, "Let's go to work."
For most of the summer, Lisa had indulged herself in the language of bad love, phrases that were smart, sassy and, ultimately, self-protecting. For reasons that we all could guess, that language had just failed her. It was not a form of expression that could stand public scrutiny in a difficult time.
David Alan Grier is the editor in chief, IEEE Annals of the History of Computing, and the author of When Computers Were Human (Princeton University Press, 2005). Grier is an associate professor in the Center for International Science and Technology Policy at the George Washington University. Contact him at grier@gwu.edu.
7 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool