Digging CACM

Archeology is an interesting, if somewhat dusty, science. Archeologists dig into the ground to unearth artifacts from antiquity and from their age-encrusted appearance and structure try to deduce their purpose and better understand the civilizations that created them.

And so it was one evening when I led an expedition down into the stygian depths of my basement in search of the earliest edition of Communications of the ACM. Amid rows of yellowing National Geographic magazines, boxes of ancient canceled checks, and fading but still blue copies of SIGSOFT proceedings I unearthed the oldest known (to me) copy of Communications—it was the February 1985 issue.

By the time I encountered CACM it was already a highly evolved organism. The earliest known direct ancestor of today’s magazine has been carbon dated as far back as 1958. This proto-CACM included such advances in computation as a (language-free) implementation of Newton’s square-root formula and the use of tables to calculate a least-squares approximation. It also included a binary counter for use with an IBM 650 calculater (sic) including the actual core locations, the decimal machine instructions (in Linear-C?), and the explicit branch memory addresses (this was before “direct program memory branch addressing considered harmful”). The article also included a delightful handwritten flowchart of the process—the software engineering equivalent of the Lascaux cave paintings.

Fast-forward through several computing epochs to the year 1985 and my first exposure to CACM, at least as identified in the historical record. The articles in this February 1985 edition give us examples of how the business of software has changed and how it has remained the same.

Programming Pearls. In the “Programming Pearls” column, we learn of a programmer who can log in while seated but gets locked out if he stands up. There is an international banking system that stops dead when someone enters the capital of Ecuador. And we also find, courtesy of the research of the indomitable Donald Knuth, that 70% of code typically consists of only four statement types. Has any of this changed? My unscientific observation of modern systems is that weird defects have not become an extinct or even endangered species, and even if the actual number of statement types used remains quite small, the job is still to get them right.

Grosch’s Law inferred that the cost of a computer will rise as the square root of its power. The fastest IBM mainframe at that time, a 3081, could cycle around 10 MIPS and cost a mere $3.7 million. Given that today’s Xbox can hit 6,400 MIPS it should therefore cost around $93 million. Clearly, Moore’s Law has trumped Grosch’s Law.

Readability. In a study on the readability of major computing periodicals, CACM scored in the “Difficult” range of the Flesch Reading Ease Index. It scored higher (more readable) than any of its major competitors at the time—the most difficult to read being the IBM Systems Journal, which was rated as solidly in the “Very Difficult” category. Of course, some elements in our profession believe that if something is relatively easy to read it cannot be worthwhile. However, when the job of a magazine is to communicate it would seem that any effort put into making that communication more efficient would be valuable. I think CACM continues to invest heavily in this area. Certainly these days it is much easier to read than some of the 1985 benchmarks such as-then-number-one in circulation Infosystems, number two in circulation Datamation,¹ number three in circulation Computer Decisions and the much-missed number four Mini-Micro Systems. Clearly there has been a Darwinian process at work.

Niklaus Wirth won the ACM A.M. Turing Award in 1984. In his address published in the February 1985 issue, he discusses his pursuit of an “appropriate formalism” in programming languages and describes some of the common characteristics of the projects that informed his view of languages at the time. They included the idea of a bootstrap tool that provided capability but more importantly acted as the basis for the next generation or iteration. He identified the need to separate requirements and capabilities into the essential and the “nice to have.” He thought the choice of tools important but that they must not require more effort to learn than they save. And, most importantly, he viewed each project primarily as a learning experience supported by the most essential (though “elusive and subtle”) element of an enthusiastic team that collectively believes in the worth of the endeavor. Well that hasn’t changed.

Selecting Decision Support System (DSS) Software was a cogent and useful article on how to select DSS including, if I perceived correctly, screen shots from Lotus 1-2-3. The striking thing is that none of these systems exist now, though some have probably evolved into today’s offerings. The evaluation criteria with a few deletions (such as the ability to produce “basic plots and charts”) could serve as a starting point for an assessment capability today. Curiously, none of them mention service-oriented architecture or even Web access.

The article really addresses a process for selection rather than what is being selected. While the target software has changed considerably, much of the process for selecting it could still apply. This just goes to show that software and systems come and go, but process lives forever.

Programmer Productivity. Starts off with a complaint about the dearth of empirical research in the kinds of tools that really help programmers. The list of software tools desired by programmers in 1985 shows how far we’ve come in this area (screen editor anyone?)

Event Simulation Modeling Language. With 56 cited articles, this article on a condition specification (CS) language as part of a model specification (MS) language could have been written yesterday. It doesn’t seem that this aspect of software engineering and computer science has advanced as it should given such a start.

Efficiency of List Update and Paging Rules. This article alone must have pulled the magazine’s Flesch Reading Ease Index down by a good 20 points. Well, it was in the “Research Contributions” section, so that would explain the six theorems and their associated proofs embedded in the article. While not everyone’s cup of t_i it showed the breadth of topics in this magazine and might well have appealed to those also interested in the…

…Positions Vacant in Computer Science. I counted 186 positions in computer science and software engineering in universities and colleges around the world (but particularly around the U.S.), 31 calls for papers just for February 1985–May 1985, and 184 conferences, symposia, workshops, expositions, and general meetings through early 1986. Clearly, a lot was going on in 1985 and CACM was keeping readers up to date on what that was. Perhaps today the academic appointment market is not quite as brisk as it was, but there are still many conferences, expositions and, yes, meetings.

Like analyzing dinosaur bones, sampling one edition of a magazine with a history as long as Communications of the ACM in a discipline with a history as short as software engineering only provides a snapshot of what is an evolutionary process. The business of software and CACM (and to some extent myself personally) have grown up together. Whenever we grow and evolve, we can always look back a few years and see ideas and approaches that seem dated and strange now. But we can also see things that truly communicated what was going on at that time in our profession, located our knowledge in a pertinent, topical, and readable form and also pointed to the future of our profession.

It is interesting and instructive to look back and see where we’ve come from. But it’s even more interesting to ponder what is coming, and it is good to know that, whatever it is, Communications of the ACM will be there communicating it to us.

Back to Top

Back to Top