Diversity Examples Inappropriate

I read the Opinion column “Science Needs You: Mobilizing for Diversity in Award Recognition” (Communications, August 2024), written by distinguished computer scientists, with mixed feelings. In 2024, the importance of diversity is well established, and it is universally recognized as a valuable goal. However, I believe that while diversity should be encouraged, it does not directly pertain to the core of computer science and technology professions.

The authors cite studies suggesting diverse groups may outperform less diverse but more talented teams. Yet, there is little convincing evidence that anything other than ability, knowledge, and communication skills drives the success of teams working in software and hardware development. In fields that are inherently merit-based, such as computer science, the focus should remain on these essential qualities.

Rather than emphasizing how many women and minority individuals have received specific awards, the focus should be placed on the outcomes achieved by professionals in science and business, regardless of demographic factors. While it is important to support underrepresented groups in pursuing careers in technology, awards should be granted based on merit alone.

Patronizing underrepresented groups does them a disservice and may undermine both scientific progress and business innovation. Let us focus on creating equal opportunities and ensuring all individuals, regardless of background, can succeed on their merits.

Leonard Gradus, Marblehead, MA, USA

Authors’ response:

We thank the reader for engaging with our Opinion column. Our perspective is that it is important for organizations such as ACM to be considerate of all of their members. Not everyone starts on the same footing or has the same connections, so some deserving of recognition may not receive it if we continue as we have historically. Importantly, our aim is not to change how award winners are chosen but to increase the pool of nominees from backgrounds that may have lower chances of being considered in the first place. We see little downside to offering more choices for award committees.

Elizabeth Novoa-Monsalve, Boulder, CO, USA
David A. Patterson, Berkeley, CA, USA
Stephanie Ludi, Denton, TX, USA
Daniel E. Acuna, Boulder, CO, USA

Myths Are Not Myths

I was a little mystified as to where the Opinion column “The Myth of the Coder” (Communications, September 2024) was going. If the endpoint were that AI won’t automate programming and that the idea has been hyped, I would agree.

However, the authors seem to deny there is a clear distinction between coder and programmer. They cite historical precedents in von Neumann and Goldstine and then Grace Hopper, but then conclude there was little historical evidence for this as common thinking. I would go with the great minds rather than what is commonly believed.

The essential difference between coding and programming is often lost. In the early days, coding required little analytical skill, only the ability to unconsciously translate (an important facility in WWII codebreakers). It was quickly recognized this was an automatable task, ideal for computers.

Programmers could express themselves in programming languages and let a compiler code generator take care of the mechanical translation. The function of coder as a person disappeared.

Whether the authors recognize the coder/programmer distinction or not, it clearly exists, or at least between the activities of programming and coding. Many people degenerate programming to coding as something machine-oriented and cryptic. Since the 1950s, we have tried to remove that impediment to programming. Programming should be expressive, literate, and an “art” (in the Donald Knuth and Bob Barton sense). Programming is removed from the machine to abstract computation. Many of us have learned how specific computers work, later (perhaps decades) realizing that is the wrong view.

It is not the computer (they are fleeting), but the invariant subject of computation and how we think that is important. Too much teaching is about how machines work, neglecting that the lasting subject is about computation. The distinction between machine-oriented coding and problem-oriented abstract programming is clear-cut. We should also distinguish between system programming, which is platform and machine oriented as a physical resource manager, and general programming that deals in logical problem-oriented resources. Programming languages should reflect the distinction and aid and express the activity of design at different levels.

System programming, which also should not be coding, is about managing the container (memory management), most programmers should be concerned with the contents—what is the information we are processing, what is its nature, and what are the abstract operations applicable to that data? System software maps logical requirements (contents) to physical resources (container).

Again much teaching is system oriented, and higher-level thinking is missed, particularly that it is the job of system programming to provide the platforms on which general programming can take place. System ‘coders’ became the high priests of computing with their mystical incantations holding onto their power (Turing, Backus, Barton). We need computational thinking, and should think like programmers, not coders.

Ian Joyner, Sydney, Australia

Authors’ response:

It is argued in our Opinion column that, while there is a clear distinction between the activities of coding and programming in the late 1940s and early 1950s, this does not translate to a socioeconomical distinction between the professions of programmer and coder. People who programmed also coded. The claim that coding required only “the ability to unconsciously translate” underestimates this practice and we challenge any reader to try and do the exercise with an original flow diagram of von Neumann and Goldstine.

The fact that developing the first compilers and high-level programming notations took over a decade actually illustrates this difficulty of transitioning from a manual to a partially automated practice. It is only after the development of higher level programming languages that people like Barton will make the argument that higher level thinking should influence how computers are designed, but by then we are already in the 1960s.

As historians, it is our “job” not to confirm or support what the “great minds” claimed but to critically examine those claims and to follow the facts. Here, the facts show that there was no separate job for the “coder” (though hierarchies on the workfloor did exist and changed through automatic programming). Today, when the high priests of Big Tech make all kinds of claims to sell their products, such critical examination is perhaps even more needed than ever before.

Liesbeth De Mol, Lille, France
Maarten Bullynck, Saint-Denis, France