Tripreport E.W.Dijkstra W.G.2.3. Baden, 1-5 September 1975.

I am very sorry to report that travel by international trains through Western Europe is no longer what it used to be. Coen Bron --from the University of Technology Twente-- and I travelled with the "Holland - Wien Express", and it sounded all right! We went aboard the train in Arnhem on Sunday afternoon at 4 o'clock. We knew that at Emmerich the dining car would be attached and we looked forward to our evening dinner while going through that beautiful part of the Rhine valley: we intended to eat our meal with the setting sun colouring the Lorelei. Great was our disappointment, when we discovered that the diner had been replaced by a help-yourself-snackbar, full of the noisy unwashed young travellers that one tries to avoid as much as possible. There was no "music" --the kind of audible wallpaper that now pollutes air ports and shopping centers!--, but that is the best I can say about the snackbar. After a miserable meal I had an excellent night on board of the sleeper. Five nights later, on our trip back, I would hardly sleep, because there wsa something basically wrong with the support of the carriage: it bumped and jumped and tossed me through my bed, that I sometimes feared a derailment... On the way back I did not sleep at all.

We arrived in Vienna at half past six in the morning, and at the end of the platform I recognized the great Teufelhart, waiting for us to pick us up. (I had hoped something of that sort, Coen was absolutely surprised by that excellent service: the difference being that I knew Teufelhart's efficiency, which was new for him.) We had breakfast in Baden's Parkhotel with the other members of the IFIP Working Group W.G.2.3 on "Programming Methodology". Of the people present I can remember Horning, Randell, Reynolds, Dahl, Ross, Gries, Hoare, Woodger, Naur, Bron, Parnas, Hönke, Sintzoff, Burstall, Jones (Cliff), Belady and Jackson (Michael), and there were still a few more.

Zemanek welcomed us, and then Mike Woodger --our excellent chairman-- opened the meeting in his usual informal way by making a schedule for the next of the week: two sessions in the morning, two sessions in the afternoon, morning sessions separated by a coffee break, and afternoon sessions also being separated by such a break. (In the morning from 9.00-10.30 and 11.00-12.30, afternoon 14.00-15.30 and 16.00-17.30.) The idea of these sessions is that participants report on their most recent work, either for the instruction of the other members or as a means for soliciting comments. The usual pattern is that each time a speaker fills all of his slot speaking and that there is not too much discussion on his talk in the slot itself. This is not too amazing, for usually the audience indeed needs all of the ninety minutes "to catch up" with the speaker. Comments on the things raised usually come later in the week, during dinner, in the evenings, etc., but usually outside the official sessions. In this respect I was very lucky to be the first speaker. I presented EWD 508 "A Synthesis Emerging?", a paper of which the ink was hardly dry. I am very glad that I had the opportunity to do so as the comments were very encouraging. The paper triggered quite a lot. On Tuesday Tony Hoare presented an equally fresh and also somewhat tenative paper "A constructive semantics for a programming language." which at first sight I did not like at all, at second sight I liked it better. On Wednesday afternoon --the traditional "afternoon off"-- he prepared his second presentation, that was to take place on Thursday morning: he used that opportunity to apply his descriptive techniques to the constructs I had introduced on Monday morning, and that was very illuminating for both our subjects.

On Monday morning when I started to describe how --via Tony's explanations in Marktoberdorf last month-- I had finally understood the quintessence of the SIMULA Class concept and had the feeling that I was describing something quite neat, clear and consistent, it was very noticeable that the one in my audience who had the greatest difficulty in grasping what I said was ... Ole-Johan Dahl --the designer of SIMULA-- himself! Not surprising: for him the amount of necessary "unlearning" was greater than for anyone else in the audience. To observe his struggles in grasping what I was explaining was most instructive; it confirmed me in my opinion that one must be very careful in the selection of to what one is going to expose oneself intensively, and it confirmed me also in the opinion that I have been right in staying away from SIMULA classes for such a long time. Had I really studied them, the discovery of synthesis would probably have been much harder. (I mention this, because Ole-Johan's struggles relieved me of a sense of guilt...)

The next presentation that should be mentioned was by Jim Horning, who showed the quintessence of the thesis by John v. Guttag "The precise specification of abstract data types." This looked very promising, not in the last place because he applied the techniques on something more ambitious than just the stack --in user-defined data types the stack seems to become the canonical example, very much like Euclid's algorithm at the algorithmic side!-- but, for instance, to a block-level symbol table. (One can argue --in fact I did-- that this is only a "fancy stack", but yet...; he then told us that they had applied the techniques to more.) As a means for interface definition it looked good, not in the least place because Guttag's specifications seemed to tune in nicely with our current proof techniques, and seemed to do so at both sides of the interface.

Two talks by David Gries --based on the work of Susan Owicki-- were very well received. In one of them he applied the proof techniques to the on-the-fly garbage collector --as he had done in Marktoberdorf. As the on-the-fly garbage collector was new for a large part of the audience, this was doubly instructive for the group as a whole, that experienced David's presentation as refreshing and again, encouraging, because from different sources different concerns had been met. Sintzoff showed a very nice --because constructive-- thing. He showed how --in principle, at least-- given synchronizing conditions could be strengthened in a systematic way so as to exclude the danger of deadlock. I say "in principle" because it was not clear (yet?) whether his formal manipulations would lead in a finite number of steps to the final answer; in his examples this was the case, but that was all. Wait and see!

I had my second slot at Friday morning, 9 o'clock, after IBM had offered us the farewell party on the preceding evening: not the easiest moment of the week for addressing the audience! I used it to show my exercises with making given programs in such a way that single machine malfunctions would not remain undetected. The discussions that followed confirmed my feeling that the path should be pursued. On the original document EWD482 "Exercises in making programs robust" I had received very little constructive comments. The exercise was just difficult and, besides that, most people like to believe that machines don't make errors. I now think, that I can see an argument that shows that with such global --and perhaps "tailor made-- redundancy, a degree of safety can be achieved that none of the other known techniques can attain. That probably means a lot of hard work, and if the result is really convincing and valid, a lot of writing to be done to make it available for a wider public. Again: wait and see!

So much for technicallities (is that spelled correctly?): the morning is drawing to a close and I would like to have this tripreport completed before I leave this afternoon for Newcastle.

At meeting like this one cannot help to pick up all sorts of inside gossip from universities, governments and machine manufacturers. Most of the gossip was depressing. I found much of the "scientific stagnation" that I saw recently at a number of universities, faithfully reflected within IBM; it confirmed my impressions that inside that company the appreciation for scientific research is dwindling rapidly. The first unmistakable symptoms showed up year ago --was it around the time that Brian Randell returned to the UK?-- when the status of Yorktown Heights was changed. (I am not quite sure about the jargon: I think it became a "research division".) The true scientist has one concern he had better never forsake: to strive after perfection. Only too often today he is expected (or pressed or forced) only to make the best of a bad job (or sometimes even worse: an impossible job). The results are terrible. On the one hand, he has to silence his own doubt and to close his eyes for the "badness" thus corrupting his carefully grown judgement. On the other hand, his employer --be it manufacturer or government-- gets very dissatisfied with his performance. If you ask a silly question, you get a silly answer! We all know that. But as soon as the scientific community has accepted a silly question as if it were a sensible one, misunderstanding and intellectual corruption set in. By accepting it as a sensible question, the other side is made to believe that the question makes sense; and when the acceptable answer fails to be given, the scientist is blamed for his "shortcomings". In the case of IBM the matter is exceptionally bad, because they really seem to believe that the 360 is "the final answer", not because it is good --they know very well that it is a lousy design-- but because it is there. Sometimes one gets the alarming impression that scientific activity fills IBM more with fear than with hope. And that would really be alarming, for that corporation is too large a body of our society to be ignored. I had a peep into a few intellectual infernos!

Another thing that struck me was the extent to which for some people "the dollar is their unit of thought"! It occurred most clearly as a reaction to my talk about robustness. Faced with the practical problem of making machine-produced results more trustworthy, one can --and should!-- invent the logical problem and the principles of its solution. To a large extent one can do so without any assumptions about the actual probability of certain forms of malfunctioning. I found a number of the people present unable to do so: they immediately argued that in view of the unlikelihood of a specific form of malfunctioning I was considering, the additional cost of my solution was unjustified. I could not explain to some of them the fundamental difference between

1. the analysis how, according to a given set of rules, a "perfect" solution would look like
2. the decision to implement a "perfect" or an "imperfect" solution.

Some engineers are amazing creatures!

When I came home, we had the most delicious climate: the flowers in the garden were blooming, the butterflies danced in pairs in the air, and with the fledglings grown up, all birds seemed to have a wonderful holiday. The sun was shining most of the day, a fresh breeze made the trees wave their branches --which still have most of their leaves-- and gentle clouds were aimlessly drifting through the sky as if they had nothing else to do. A perfect autumn day!