1985 Dijkstra interview

Posted on October 10, 2007 by Tommy McGuire
Labels: Dijkstra, programming language
I just ran across this interview with Dijkstra (via another blog entry, via a Google search). The interview has many interesting ideas:
User-friendliness is a word that never should have been invented....The point is that the computer user, as functioning in the development of computer products is not a real person of flesh and blood but a literary figure, the creation of literature, rather poor literature....He is stupid, education resistant if not education proof, and he hates any form of intellectual demand made on him, he cannot be delighted by something beautiful, because he lacks the education to appreciate beauty.
Strangely, this is almost the exact same reaction I had to an IBM Redbook documenting TCP/IP configuration for OS/2; I tore out the three pages that had useful information and threw away the remaining 100+.

On programming languages:
For a long time features of programming languages were included on account of their supposed popularity—the main criterion was will people like it—again stemming from a rather dismal perception of the user. The great change in programming languages came from the fact that we started giving formal definitions of the semantics of programming language concepts. Something you need if you want to be able to prove things about the programs written in it. And even if you do not intend to do that in a formal way, it was an extremely healthy exercise for programming language designers. Formalization acted as an early warning system: if the formal definition of a feature gets very messy and complicated, then you should not ignore that warning.

Further, on programming languages and logic, and the difference between imperative and non-imperative programming:
Others are trying to be in their considerations even less constructive. They define the answers by a number of logical equations, leaving it to the implementation to find the solution to that set of equations. The net effect of it seems to be that a full system for really acceptable programming will be at the same time a full system that will suffice for the description of constructive mathematics. What is happening is that the gap between a program a computer may execute and the mathematical proof that the answer exists is narrowing. The simplest way to characterize the difference between imperative programming languages and non-imperative ones is that in the reasoning about imperative programming you have to be aware of the 'state' of the machine as is recorded in its memory. In conjunction with that there is a clear distinction between a program on the one end and the information processed on the other. In the case of functional programming you create a language in which you can write all sorts of expressions and evaluating an expression then means massaging that expression until you have it in the shape that you want to have it in.
And, in a more depressing note:
Well, we is a rather mixed lot aren't we? Let me give you three dates 1968, 1975 and 1984.
In 1968 IBM published an ad in Datamation showing Suzie Meyer smiling in full color. Suzie Meyer announced that she had solved all her programming problems by the simple trick of switching over to PL/1. It is a great pity that Datamation did not publish a picture of Suzie Meyer four years later!
1975 was about the time that the Swedish logician Per Martin-Löf convinced himself of the fact that a well documented program was an object logically isomorphic with a constructive mathematical proof. In that sense the word constructive refers to the most puritan of all mathematics.
By 1984 the computer science had taken notice of that fact. Late 1983 I attended a small industrial conference on programming. One message came across loud and clear and that was that in development of programs formal techniques would not only be indispensable, but would have to be applied on a scale without precedent. Now if you compare that with then we have travelled long and far.


Powered by ScribeFire.

active directory applied formal logic ashurbanipal authentication books c c++ comics conference continuations coq data structure digital humanities Dijkstra eclipse virgo electronics emacs goodreads haskell http java job Knuth ldap link linux lisp math naming nimrod notation OpenAM osgi parsing pony programming language protocols python quote R random REST ruby rust SAML scala scheme shell software development system administration theory tip toy problems unix vmware yeti
Member of The Internet Defense League
Site proudly generated by Hakyll.