Edsger Dijkstra

In Pursuit of Simplicity Presentation slides of A Symposium Honoring Professor Edsger Wybe Dijkstra May 12–13, 2000

A Case against the GO TO Statement.

Famous quotes

Articles and books by and on Edsger Dijkstra

On my bookshelf
On my bookshelf
On my bookshelf
Structured Programming
O.J. Dahl, E. W. Dijkstra, C.A.R. Hoare
E.Q. Dijkstra PhD thesis
A Discipline of Programming
ALGOL The Dijkstra Zonneveld ALGOL-60 Compiler
for the X1, sources, stories, explanations
F.J. Kruseman Aretz
In Pursuit of Simplicity.pdf
The Man Who Carried Computer Science on His Shoulders
Krzystof Apt

Edsger Dijkstra archive, the manuscripts

Edsger W. Dijkstra

Edsger W. Dijkstra

How do we tell truths that might hurt?
Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling them, however, will fire back on us. If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you. (Besides that, telling such truths is a sure way of making oneself unpopular in many circles, and, as such, it is an act that, in general, is not without personal risks. Vide Galileo Galilei…..)

Computing Science seems to suffer severely from this conflict. On the whole, it remains silent and tries to escape this conflict by shifting its attention. (For instance: with respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist. Most Computer Science Departments have opted for the latter easy way out.) But, Brethren, I ask you: is this honest? Is not our prolonged silence fretting away Computing Science’s intellectual integrity? Are we decent by remaining silent? If not, how do we speak up?

To give you some idea of the scope of the problem I have listed a number of such truths. (Nearly all computing scientists I know well will agree without hesitation to nearly all of them. Yet we allow the world to behave as if we did not know them….)
*

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
The easiest machine applications are the technical/scientific computations.

The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.

FORTRAN —”the infantile disorder”—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.

PL/I —”the fatal disease”— belongs more to the problem set than to the solution set.

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.

About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.

Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems.

We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer.
The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.

In the good old days physicists repeated each other’s experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other’s programs, bugs included.
Projects promoting programming in “natural language” are intrinsically doomed to fail.

Isn’t this list enough to make us uncomfortable? What are we going to do? Return to the order of the day, presumably…….
18th June 1975
NUENEN

The Netherlands prof.dr.Edsger W.Dijkstra
Burroughs Research Fellow
PS. If the conjecture “You would rather that I had not disturbed you by sending you this.” is correct, you may add it to the list of uncomfortable truths.
EWD

Home

News

Pascal P3 compiler, VU Pascal compilers, Pascal-S

Thanks to a tip by Stefano B., who found tape dumps of university archives I have added: Compilers developed at the ...

Read More

Oberon for PICO RP2040 (and PICO 2 RP2350)

Oberon is still alive. Chris Burrows of Astrobe has maintained and added a lot to his Oberon compilers. New are support for ...

Read More

Oberon Pi

Oberon Pi

Oberon, the jewel by Niklaus Wirth and Jürg Gutknecht: Operating System, Compiler and Computer. Oberon Pi is a port of Peter ...

Read More

Sources of 1900 Pascal Compiler MK 2

Additions to the Jim Welsh pages, Queen’s University Belfast and Emerate Professor at The University of Queensland Brisbane, School of ...

Read More

Apple Lisa Pascal compiler sources

I found an archive with the source of the early Lisa Pascal by Silicon Valley Software. The archive contains images of ...

Read More


DSC_3541
This site is about my experience with the Wirth school of languages, based on the ideas and implementations of Prof Niklaus Wirth, Kenneth Bowles, Per Brinch Hansen, colleagues, and their students. And my experience with the various variants, from the P2 and P4 compilers originating in Zürich ETH, via UCSD Pascal P-System to the Borland compilers and Modula and Oberon systems. All applicable to small computers and device control.

On this website you will find information on Pascal for small machines, like Wirth compilers, the UCSD Pascal system, many scanned books and other files on UCSD Pascal, Pascal on MSX and CP/M, Delphi programming on PC, Freepascal and Lazarus on Windows and Raspberry Pi, Oberon systems. Many sources of early Pascal compilers! And last but not least my Pascal-M system!

On this site you will information on (see the menu on the right!)
Standard Pascal and Validation
Niklaus Wirth
Edsger Dijkstra
Per Brinch Hansen
Ca.A.R Hoare
Jim Welsh
Pascal Px descendants like P5 and Pascal-M
UCSD Pascal
– Other Pascal articles like Freepascal on Raspberry Pi, Turbo Pascal and Delphi and electronics

Timeline of my exposure to the Wirth language and OS and systems family, 5 years as student, 10 years as software engineer, hobby, 40 years as the way of programming!

  • WIRTH (1)1970- Pascal compilers, the P2-P4 compilers, Pascal-S, Pascal-VU (the forerunnner of the Amsterdam Compiler Kit), Andrew Tanenbaum, Professor R.P  van de Riet.
  • 1979 – Pascal-M
  • 1980 – UCSD P-System, HP Pascal 1000
  • 1983 – RSX-11M VMS Pascal
  • 1985 Turbo Pascal, , 10 years VAX/VMS Pascal programmer, teacher of the Teleac support course Pascal, teacher and examinator Exin/Novi T5 Pascal
  • 1990 – Turbo Pascal 3 on CP/M and MS DOS to Delphi on Windows
  • 2010 – Freepascal + Lazarus on Windows and Linux