Open AccessBook
The humble programmer
Edsger W. Dijkstra
- 01 Jan 1979
- pp 111-125
725
TL;DR: As a result of a long sequence of coincidences I entered the programming profession officially on the first spring morning of 1952, and as far as I have been able to trace, I was the first Dutchman to do so in my country.
read more
Abstract: In my opinion, Dijkstra's "Humble Programmer" ought to be required reading for everyone who claims that programming is his or her profession. To me, it ranks as one of the great classics in the field, providing an educational experience for the junior programmer, and truly delightful reading for the veteran. It serves as a wonderful reminder of the good old days of the computer field, and offers an excellent summary of the philosophies and guiding principles by which we try to do our jobs. The concepts expressed are eloquent and profound, sometimes controversial, and generally thought-provoking.
I worry that some of the most eloquent remarks cannot be appreciated by today's programmers: For example, Dijkstra says, " . . . when we had a few weak computers, programming became a mild problem, and now that we have gigantic computers, programming has become an equally gigantic problem." Most of us who began our careers on 1K or 4K machines will smile in appreciation, but will the remarks mean anything to the programmer of the 1980s who will begin his or her career on a 16-megabyte computer? When Dijkstra states, " . . . one of the most important aspects of any computing tool is its influence on the thinking habits of those who try to use it," I wonder whether today's hobbyist programmer, with his buildit- at-home computer and subset of BASIC, has any idea of what Dijkstra is talking about.
There are the controversial comments, too: For instance, Dijkstra refers to FORTRAN as an infantile disorder, and PL/I as a fatal disease. Curiously enough, even though he praises such obscure languages as LISP, he does not seem to acknowledge the existence of the two languages that account for probably 75 percent of all the computer programs written today: COBOL and RPG.
It is in this paper as well that Dijkstra suggests that the primary resistance to the so-called structured revolution will come from educational institutions, and from the political backlash of an EDP organization that would prefer to maintain the status quo. I personally agree with this, having experienced such resistance first-hand in my own work as a consultant and educator. You may or may not agree, but you certainly will find Dijkstra's comments worth reading.
read more
Chat with Paper
AI Agents for this Paper
Find similar papers on Google Scholar, PubMed and Arxiv
Write a critical review of this paper
Analyze citations of this paper to find unaddressed research gaps
Citations
•Book
Software Engineering: A Practitioner's Approach
Roger S. Pressman
- 01 Jan 1982
TL;DR: Software Engineering A Practitioner's Approach recognizes the dramatic growth in the field of software engineering and emphasizes new and important methods and tools used in the industry.
10.4K
The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering
TL;DR: A set of principles for designing cognitively effective visual notations: ones that are optimized for human communication and problem solving are defined, which form a design theory, called the Physics of Notations, which focuses on the physical properties of notations rather than their logical properties.
1.3K
Structured Programming with go to Statements
TL;DR: For serious students of structured programming, and also for language designers, Knuth's "Structured Programming with go to Statements" is probably the paper to read.
•Book
Structured programming with go to statements
Donald E. Knuth
- 01 Jan 1979
TL;DR: For instance, Knuth's "Structured Programming with Go-To Statements" as discussed by the authors is probably the most complete description of structured programming of all the selections in this book, and it can be used as a good starting point for a discussion of the role of gotos in structured programming.
631
Metamorphic Testing: A Review of Challenges and Opportunities
TL;DR: The current research of metamorphic testing is reviewed and the challenges yet to be addressed are discussed, and visions for further improvement are presented and opportunities for new research are highlighted.
References
Letters to the editor: go to statement considered harmful
TL;DR: My considerations are that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, and that his intellectual powers are rather geared to master static relations and his powers to visualize processes evolving in time are relatively poorly developed.
1K