
Letters between Backus and Dijkstra (1979) - acidflask
https://medium.com/@acidflask/this-guys-arrogance-takes-your-breath-away-5b903624ca5f#.3d80xpzgv
======
vanderZwan
You know, I'm wondering: could part of Dijkstra's reputed arrogance be due to
a cultural difference? I'm Dutch, and bluntly calling out flaws in each
other's work is not considered all that rude over here; it's almost the
opposite: not calling someone out on their flaws implies we either consider
them a lost cause or not worth the hassle of educating.

I almost got fired from a teaching position in Sweden because I told my 3rd
year bachelor students that many did not bother to add their names or the
assignment number, or using paragraphs and in some cases even basic
interpunction on their assignments. And that this was well below the level
required to to pass secondary school, and that I expect better from them.

This was apparently too confrontational, and a few upset students later I got
chewed out and almost fired. Meanwhile, from my point of view, I was just
doing my job and already sugarcoating it by Dutch standards.

Having said that, yes, even by Dutch standards I would say that Dijkstra liked
to troll people a bit.

PS: I really like the following insight from Dijkstra's review: _But whereas
machines must be able to execute programs (without understanding them), people
must be able to understand them (without executing them)._

~~~
bmer
Full disclosure:

a) Dijkstra is a bit of a personal "hero" of mine (hero in quotation marks,
because I don't like to think of myself as a hero worshipper), because it was
due to him I learned of textbooks written by guys like Eric Hehner and Roland
Backhouse, which ended up changing my life significantly.

b) I do not really grasp the technical issues being discussed in the
correspondences between Dijkstra and Backus

Given this disclosure:

Regardless of the cultural issues (which I suspect you are right about), I
found Backus' first response to Dijkstra _full_ of ad hominems, and very light
on technical rebuttals. If we subtract out the ad hominems, I suspect the
technical rebuttals would take less than a page (which is a significant
reduction, considering that the full letter is 4 (typewritten!) pages).

Calling Dijkstra arrogant seems to have been a popular insult (as Backus
himself admits), so I wonder if Backus was simply jumping onto the bandwagon
as a defensive reaction to the arguments presented in EWD 692.

I think Dijkstra's responses were indeed trollish. I wish he wouldn't have
said anything further after he noticed the gratuitous personal attacks against
his character in Backus' response, but he couldn't help but say something
back. Oh well.

Can you comment on this observation?

~~~
c3534l
I personally found Backus to be _way_ more of a dick in these letters, though
I did gloss over some parts. It's strange how different people can get very
different things from these letters. Maybe they just didn't have personalities
that meshed well. I don't think it's cultural: I'm American and I find
Dijkstra's demeanor to be perfectly acceptable, if a little a colorful.
Although, in the same vein, people often don't like Linus Torvalds for many of
the same reasons.

~~~
tps5
I found Dijkstra's letters appalling. Writing - utterly without shame - that
his negative response to Backus' paper was disingenuous and served a
"political" purpose is utterly despicable to me.

I don't know how you can defend that.

------
justin66
"I don't know how many of you have ever met Dijkstra, but you probably know
that arrogance in computer science is measured in nano-Dijkstras."

\- Alan Kay

~~~
alankay
This quote keeps on showing up out of context. Edsger and I got along quite
well. He loved to be the way he was and pushed it. His friend Bob Barton (the
great genius of the B5000 design) was very similar in loving to push buttons
and being very critical of the not-quite-a-field that we have. When the U of
Utah faculty complained to Dave Evans about Barton, Evans said "We don't care
if they're prima donnas as long as they can sing!" This was a general attitude
back then. Dijkstra was much more funny than annoying for anyone who had any
sense of self. The two biggest problems in our not-quite-a-field were those
who listened to him too carefully and those who didn't listen to him carefully
enough. In any case, in the research and faculty worlds of the 60s -- where
the funding from ARPA was very very different than funding is today --
consensus was not very important: really capable people explored without
worrying so much about what others thought (this is hard to explain to people
who've grown up in the intensely social and identity seeking world of the last
20 years or so). His comment about OOP (a rather different kind of thing at
Xerox PARC than what the term means today) did not bother any of us at all --
it was rather a compliment even (which was also not a big deal) for those of
us who liked the way California worked in the 70s. His comments helped when
they helped, and they mattered not at all when they didn't.

~~~
acidflask
Would you happen to have any insight into the question that brought me to go
dig through old letters in a library in the first place?

[https://news.ycombinator.com/item?id=11799143](https://news.ycombinator.com/item?id=11799143)

~~~
alankay1
Priority is tricky to nail down e.g. the EDSAC was operational a year before
the Mark 1 (which actually was not operational until 1949). Because of the "B"
Williams Tube which held the two index registers of the Mark 1, many other
manufacturers -- e.g. Burroughs -- later called their index registers "B
registers". (Also, I think the Univac I and II were successful commercially,
and earlier than the 704.)

I started programming in earnest and for money in 1961 mostly in machine code
on a variety of machines, and I'm pretty sure that the notions of single
dimensional sequential locations of memory as structures (most often called
arrays, but sometimes called lists), predated the idea of index registers.
This is because I distinctly remember being first taught how to move through
arrays sequentially just by direct address modification -- this was called
indexing in the Air Force -- and later being introduced to the index register
or registers -- depending on the machine.

My strong guess (from above) is that the array as sequential memory accessed
by address modification of some kind was a primary idea in the very first
useful computers in the late 40s, and that this idea pre-dated index
registers.

It would be well worth your time to look at the instruction set of EDSAC, and
try writing some programs.

------
weinzierl
This is a series of cell phone shots of an exchange of letters between Backus
and Dijkstra. There is no transcript and some of the letters are hard to read,
especially the handwritten ones.

I only skimmed it but it is definitely an interesting read. I didn't interpret
their stance as arrogant though. In my book both are enthusiastic about their
subject and think the other party is misguided. Both take some effort not to
hurt the others feelings while still bringing their point across.

~~~
Bromskloss
What do you say? Shall we divide the task among a few of us and type this up?
(Or do people perhaps do this with OCR nowadays?) Would there be enough
interest in having these letters in searchable form to motivate the effort?

~~~
akkartik
Unfortunately they don't seem to be in the EWD archives at
[http://www.cs.utexas.edu/users/EWD/indexChron.html](http://www.cs.utexas.edu/users/EWD/indexChron.html).
So they indeed don't seem to be OCR'd.

~~~
Bromskloss
Now that you mention it, maybe we should just turn it over to those guys to
make transcriptions and host it all. :-)

Edit: I sent a mail to the project maintainer.

------
Ericson2314
I'm sad that in this thread and
[https://news.ycombinator.com/item?id=11786193](https://news.ycombinator.com/item?id=11786193),
nobody is actually talking about the technical arguments at play. I've only
read the EWD692 "opening salvo" but already there are interesting things to
point out.

EWD1303:

> The profound significance of Dekker's solution of 1959, however, was that it
> showed the role that mathematical proof could play in the process of program
> design. Now, more than 40 years later, this role is still hardly recognized
> in the world of discrete designs. If mathematics is allowed to play a role
> at all, it is in the form of a posteriori verification, i.e. by showing by
> usually mechanized mathematics that the design meets its specifications; the
> strong guidance that correctness concerns can provide to the design process
> is rarely exploited. On the whole it is still "Code first, debug later"
> instead of "Think first, code later", which is a pity, but Computing Science
> cannot complain: we are free to speak, we don't have a right to be heard.
> And in later years Computing Science has spoken: in connection with the
> calculational derivation of programs —and then of mathematical proofs in
> general— the names of R.W. Floyd, C.A.R. Hoare, D. Gries, C.C. Morgan,
> A.J.M. van Gasteren and W.H.J. Feijen are the first to come to my mind.

Backus as quoted in EWD692 (Djikstra attacks this):

> One advantage of this algebra over other proof techniques is that the
> programmer can use his programming language as the language for deriving
> proofs, rather than having to state proofs in a separate logical system that
> merely [sic!] talks about his programs.

From a perspective of a PL person like myself, these ideals are very
compatible. Without correctness by construction, there is not enough proof
reuse so formality will forever be doomed for niche applications (aka
computers embedded in dangerous things). Likewise after trying out
intuitionistic type theory--based things (e.g. Agda) separating the program
and proof langauges just seems clumsy. Overall separating programming and
proof whether spatially (seperate languages) or temporally (correctness proved
after the fact) is bad, and the reasons hardly depend on the dimension of
separation

~~~
pron
> separating the program and proof langauges just seems clumsy.

Lamport's TLA (which serves as the basis for TLA+) is simpler than Agda
because in Agda, even though you use the same syntax for both types (i.e.
propositions) and programs, they are conceptually separate, while in TLA they
are the same. Both the program (well, its specification) and its properties
are just logical propositions. TLA+, which is untyped (and based on TLA and
ZFC) has the added advantage of being far, far (far) easier to learn than any
dependently-typed language. TLA was introduced in this paper[1], which begins
thus:

> Correctness of the algorithm means that the program satisfies a desired
> property. We propose a simpler approach in which both the algorithm and the
> property are specified by formulas in a single logic. Correctness of the
> algorithm means that the formula specifying the algorithm implies the
> formula specifying the property, where implies is ordinary logical
> implication. We are motivated not by an abstract ideal of elegance, but by
> the practical problem of reasoning about real algorithms. Rigorous reasoning
> is the only way to avoid subtle errors in concurrent algorithms, and we want
> to make reasoning as simple as possible by making the underlying formalism
> simple.

However, there is a debate between the PL approach (championed by Backus,
Milner) and the specification approach (championed by Dijkstra, Lamport) over
utility. The question is whether proving at the code level is empirically
viable (at a reasonable cost) for all but the simplest of programs. Indeed, so
far the answer seems to be no. There has been only one program ever written
and verified using dependent types (CompCert), it is certainly non-trivial but
rather small, yet it required a world-class expert, took a lot of effort, and
even then required corner-cutting (Leroy says he gave up on proving
termination, simply adding a counter and throwing a runtime exception if it
runs out). TLA+, OTOH, is used extensively and regularly by Amazon (and
Oracle, Microsoft and others), by "plain" engineers, on real-world large
systems (far larger than CompCert), and management loves it because it
actually seems to save them time and money. This is only possible because TLA+
is _not_ the programming language.

Lamport doesn't reject the theoretical possibility of a PL that could provide
large-scale verification of some sort (end-to-end verification will always be
extremely expensive due to simple complexity arguments), only points out that
no PL has so far come anywhere close to fulfilling this promise. Of course,
TLA+ doesn't provide end-to-end verification, but that is too expensive -- and
unnecessary -- for 99% of the industry anyway. I think that the ideas are
compatible, but so far in theory only, while in practice they are not (yet?).

[1]: [http://research.microsoft.com/pubs/64074/lamport-
actions.pdf](http://research.microsoft.com/pubs/64074/lamport-actions.pdf)

~~~
Ericson2314
Don't forget all the Adam Chipala stuff in Coq. Didn't know people actually
used TLA.

Even if I was programming in a separate language, I'd still want a it embedded
in a hosting type-theory so I can use it both for proofs and macros.

~~~
pron
> Don't forget all the Adam Chipala stuff in Coq

Has there ever been another non-trivial real-world program written in Coq (or
another dependently-typed language for that matter) other than CompCert?

> Didn't know people actually used TLA.

Oh, far more than Coq; possibly more than Isabelle, even. TLA+ was designed
for engineers, and evolved along with careful observation of how it is used by
them. Coq is mainly used by type theoreticians to explore proving various
mathematical theorems using ITT, and by PL people exploring various PL
theories. TLA+ is used by engineers for large-scale software[1][2][3].

> I'd still want a it embedded in a hosting type-theory so I can use it both
> for proofs and macros.

I'm not sure what you mean by macros (I'm not a type-theory person in the
least), but what does it matter if it's a type theory or a set theory?
Lamport's thesis was that just as virtually all math proofs don't require type
theory, neither do program proofs; indeed virtually none of the algorithm
proofs in computer science employ type theory at all. TLA+ is a formalization
of such proofs.

The main advantage of TLA+ is that it's as powerful as Coq for verifying
algorithms (though it is not designed for proving general mathematical
theorems), yet it any engineer can master it in weeks, without learning any
new (not to speak of rather exotic) math. Also, it is amenable (and indeed
supports) to model-checking, which alone is enough to make it practical.
Deductive machine-checked proofs (which TLA+ also supports) are just too time
consuming, and have ever been used on full programs only a handful of times.
Their main use in industry is to tie together model-checked programs[4].

TLA+'s disadvantage is that it's very hard to extract a program from a TLA+
spec. Translations going the other way (from code to TLA+) have been done a
number of times (for C and Java) but only in academia AFAIK. But this is
unsurprising as Lamport's (and Dijkstra's) thesis is that effective,
practical, program verification can only be done at a level higher than
program code (unless it's a small program, specifically written in a
simplified matter for the sake of verification, and the very large effort is
acceptable -- all three conditions that have been met in the few cases where
deductive, whole-program verification has ever been used).

[1]: [http://research.microsoft.com/en-
us/um/people/lamport/tla/fo...](http://research.microsoft.com/en-
us/um/people/lamport/tla/formal-methods-amazon.pdf)

[2]: [http://tla2012.loria.fr/contributed/newcombe-
slides.pdf](http://tla2012.loria.fr/contributed/newcombe-slides.pdf)

[3]: [http://research.microsoft.com/en-
us/um/people/lamport/pubs/h...](http://research.microsoft.com/en-
us/um/people/lamport/pubs/high-level.pdf)

[4]: [http://events.inf.ed.ac.uk/Milner2012/J_Harrison-
html5-mp4.h...](http://events.inf.ed.ac.uk/Milner2012/J_Harrison-
html5-mp4.html)

------
kazinator
Dikjstra had very good command of English for a Dutchman; far better than the
average American. It seems he could easily have taught first year English.
Look at the way he nicely incorporates quotes and the diction and sentence
variety.

From this we can tell where he placed his efforts; if you want to troll
computer science on an international level, you better beef up your English!

He would have made a great asset to any software team, as a documenter; I
wouldn't have had him write much code, though.

~~~
morty16
My understanding is that English is a natural second language for the Dutch
and is taught extensively in schools (i.e. learned by everyone). Also, they
are close enough to the U.K. to receive broadcast television, etc. so they
also have that level of immersion.

Every Dutch person I've met has had a terrific command of the language, much
better than average native speakers. I suspect that at least some of this is
due to the fact that as second-language students they actually take time to
learn the rules of grammar, etc. Most native speakers pick it up "on the
street", so the Dutch (that I've met) tend to sound more formal and educated,
especially when there's no discernible accent.

------
OJFord

        Dear John,
    
        ...
        But when you open your letter with:
            “I am quite sure that you have never read
            any paper I’ve sent you before”
        it is my pleasure to inform you that - although
        “quite sure” - you were very wrong.
    

Zing!

------
vog
Could anybody explain why this comment by "internaut" was downvoted so
heavily?

I found internaut's comment to be insightful, well-conceived and on-topic.
What's wrong with this comment?

EDIT: Moreover, who downvoted me so quickly for asking this question? This
happened almost immediately after I posted this. Are there some nasty bots at
place here?

~~~
pvg
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

search for 'downvoted'.

~~~
vog
I don't know what to make of this. This hint is not useful at all. The
guideline in question ...

 _> Please resist commenting about being downvoted._

... does not explain anything here.

1\. This guideline does not explain the downvote of internaut's comment.

2\. This guideline does not explain the downvote of my initial comment, where
I complained about _another person_ being downvoted, not about myself being
downvoted (which I wasn't at that point in time).

3\. This guideline does not explain the situation after my EDIT. Although it
violated that guideline, it did not receive heavy downvotes, but received
multiple upvotes instead.

~~~
pvg
It simply asks you not to go on (and continue to go on) about downvoting. The
forum is better if everyone does as it asks. If you're really worried about
being targeted by some evil bot, you can just email the site admins.

~~~
vog
Thanks for the clarification. Now your first comment makes a lot more sense to
me.

It was not clear to me that you were asking for something. I thought you were
trying to explain something.

~~~
pvg
I wasn't asking you for anything.

~~~
vog
You were asking me to follow the guidelines. Which is perfectly fine. I wasn't
aware that I violated them, I'm thankful for the hint, and I'm more than
willing to respect and follow them.

I just didn't get that from your very short initial comment, because I
misunderstood it.

