Hacker News Reader

You need to put it in historical perspective. Essays like this one were written at the dawn of the "structured programming" debate. If you're programming in a language and codebase where goto is rare or non-existent, then Dijkstra's ideas have had an impact on your environment.

More precisely he is always a champion of the idea of having programs express things in a direct and understandable way which makes comprehension straightforward. And a champion of getting there by removing unneeded features from languages.

This was a necessary overcorrection to now-forgotten excesses. But today it is clear that he went too far. As an example, I would consider Go's a language which is heavily influenced by Dijkstra's ideas on the value of simplicity in language design. However the internal loop exit implied by break exists. Multiple return values are used to separate out data (the result of a calculation) from metadata (the presence and details of errors). We use features beyond what Dijkstra considered wise.

There are hundreds of EWDs and I haven't seen a single one where Dijkstra would talk about making programming languages simple to make comprehension straightforward, this is something that modern programming "gurus" are more likely to say. The reason Dijkstra wants simple programming languages, and most EWDs are more or less about this, is because he wants to prove theorems about programs, which is possible only with a simple language. Not only that, as I said he wants to reduce program development to well defined transformations on a specification of a problem in the language of mathematical logic. His stance is very nicely summarized here:

http://en.wikipedia.org/wiki/The_Cruelty_of_Really_Teaching_...

You have to understand some mathematics and mathematical logic to really understand Dijkstra however, you cannot look at it from a pure software engineering background because you will only take away platitudes from what he says without actually understanding him. If you have some background you can read about his real technical ideas:

http://en.wikipedia.org/wiki/Program_derivation

http://en.wikipedia.org/wiki/Guarded_Command_Language

http://en.wikipedia.org/wiki/Predicate_transformer_semantics

This is the area Dijkstra worked most on during his research career. Those ideas actually go back centuries before anyone ever thought about structured programming. For hundreds of years there has been a fundamental debate ongoing on whether all kinds of reasoning can be reduced to some kind of calculi with well specified rules, which would be equivalent to being able to construct a (at least theoretical) machine for automating it. This is where computers come from, this goes back to Charles Babbage, to the works of Leibniz, Boole, Turing etc.

Dijkstra is in the same historical tradition. The program I understand Dijkstra has for Computer Science is similar to the program Hilbert had for mathematics with what is now called formalism, from which the work of Goedel and Turing sprung off. When programming was still mainly done by mathematicians this has been a lively research area, there were various systems of proving correctness invented, various ways of deriving programs, there has been a very heated debate on when proofs are needed and to what extent ordinary programmers have to master them etc. You can find loads of books and monographs written in the 70s and 80s about this. Now as far as research goes program derivation seems to be an almost dead topic, but there are still people today championing it in some alternative form. Richard Bird wrote a book called "Pearls of Functional Algorithm Design" where he derives algorithms using algebraical properties:

http://www.cs.ox.ac.uk/people/richard.bird/

Alexander Stepanov has been advocating something similar and wrote a book called "Elements of Programming":

http://www.elementsofprogramming.com/

https://www.youtube.com/watch?v=Ih9gpJga4Vc

There are hundreds of EWDs and I haven't seen a single one where Dijkstra would talk about making programming languages simple to make comprehension straightforward...

If that's the case then you need to read more closely. This discussion is sparked by http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW.... I'll focus on just two statements from this one which demonstrates the theme that I said was there:

Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control.

It would be hard to find a clearer advocation of simplicity in programming languages.

But a clearer statement of his priorities - and why they are priorities - can be found here:

A study of program structure had revealed that programs —even alternative programs for the same task and with the same mathematical content— can differ tremendously in their intellectual manageability. A number of rules have been discovered, violation of which will either seriously impair or totally destroy the intellectual manageability of the program. These rules are of two kinds. Those of the first kind are easily imposed mechanically, viz. by a suitably chosen programming language. Examples are the exclusion of goto-statements and of procedures with more than one output parameter. For those of the second kind I at least —but that may be due to lack of competence on my side— see no way of imposing them mechanically, as it seems to need some sort of automatic theorem prover for which I have no existence proof. Therefore, for the time being and perhaps forever, the rules of the second kind present themselves as elements of discipline required from the programmer...

Your complaint is essentially that I focused on rules of the first kind described, when Dijkstra did a lot of work on rules of the second kind. If I were truly doing that then I'd be failing to understand him exactly as badly as you are in saying he was only interested in rules of the second kind while ignoring the fact that his largest concrete impact came from http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T....

I recognize and value his work in both areas. However the question that was asked was about his impact on current programming practice. And there is no question that his ideas on structured programming have had more impact than his ideas on provably correct software.

I try to read this paper from the perspective of his overall work and writing, and I have read through a lot of the EWDs. There is an abundance of examples that his #1 concern was about making programming more mathematical. Hence I interpret everything that you are quoting as proposals motivated by the need he perceives of proving programs correct. That the industry trivialized his ideas to "don't use goto" does not mean this was Dijkstra's great point. This is in fact excellently summarized in the first link I posted. Meanwhile you make it sound like he was interested in contributing to software engineering like it is done today, which is not the case, he seemed to really despise a lot of the things which are now software engineering best practices, like unit tests.

What I actually hoped for is someone who really learned the way of writing programs Dijkstra advocated to some extent and their experience with it. I can't say I really understand how those derivations look like in practice.

I try to read this paper from the perspective of his overall work and writing, and I have read through a lot of the EWDs.

In other words you're missing the plain meaning of the sections that I quoted because you try to consider it in the light of http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EW... which was written a decade and a half later? Pardon me, but I won't be emulating your example.

The focus of Dijkstra's research career was how to make correct software. As he himself would claim, there are two halves to this process. The first is to limit ourselves to forms of writing code which are easy to reason about. The second is to actually perform that reasoning.

The part of his proposal that actually had an impact is the part which says that we need to focus on methods of expressing ourselves that are easy to reason about. The part that did not have a direct impact is the part which says that we need to perform that formal reasoning. The fundamental reason why not is that Dijkstra's reasoning assumed the existence of a consistent, unchanging specification. The real world does not work that way - computers exist to do what humans ask. And humans do not always ask for things that make sense.

This is not to say that this is the impact that he wanted to have - it is clearly not - but it is the impact that he did have.

However some of his other ideas have indeed found their way into practice, albeit in a muted way that he would have objected to. For example take unit tests, since you brought them up. He was against tests as part of including QA as an integral part of the programming process - if the programmer performed properly then that should not be needed. (Nice theory, fails in practice.) However today, well-designed unit tests do serve as a limited form of specifying exactly what a given piece of code is supposed to do, and verifying that it in fact does that. (I'm sure that he would say limited and inadequate. But it is better than nothing.)

In other words you're missing the plain meaning of the sections that I quoted because you try to consider it in the light of http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EW.... which was written a decade and a half later?

This clearly shows you haven't actually studied his writings, because he has been raising the same points for many years in almost every EWD, OP is EWD340, so here is a sample from before this period:

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...

For example from EWD317:

If we take the existence of the impressive body of Mathematics as the experimental evidence for the opinion that for the human mind the mathematical method is indeed the most effective way to come to grips with complexity, we have no choice any longer: we should reshape our field of programming in such a way that the mathematician's methods become equally applicable to our programming problems, for there are no other means. It is my personal hope and expectation that in the years to come programming will become more and more an activity of mathematical nature.

For a programming language to be simple in the sense of being able to prove things is a completely different thing than for it to be simple in the sense of being easy to understand informally. Yes, bastardized versions of his ideas did make it into the mainstream, I doubt it's always even because of his direct influence and that's what the wiki article I posted three comments earlier is about.

According to Daylight's book The Dawn of Software Engineering: From Turing to Dijkstra, Dijkstra actually advocated adding recursion to Algol 60 despite not having good reasons to use it himself. He felt that it made the language more general, while his detractors at the time felt that anything unnecessary (especially anything potentially having a negative performance impact) amounted to waste. Dijkstra was a vocal opponent of putting machine-specific stuff in the language. History seems to have borne out both.

I think it's a bit of a dilution of his message to say he was a champion of comprehensibility. He was more interested in correctness, and his dream was that formal methods would be foundational to software development. That clearly didn't happen.

it takes 300 pages for him to get to the point of developing simple algorithms of the type you meet in the first chapter of an algorithm textbook

That's impossible; Discipline of Programming has only 217 pages of text. Surely you've been so enthralled by your reading that you didn't notice skipping through the covers to the book laying below!

I (re)learned programming this way. I studied CS at Eindhoven University of Technology, where Dijkstra ran a research group for years.

You need to understand that Dijkstra's primary research focus was algorithms. Mathematically deriving algorithms from formal specifications isn't a weird idea at all. Sure, it feels cumbersome when the algorithm you're deriving is a commonly known one, like a mergesort or a binary search. The idea is that you can derive other, more specific algorithms in the same way, and you'll have proven their correctness.

These days, algorithms are not a major part of most computer systems. Trying to apply Dijkstra's approach to a user interface or a JSON parser makes little sense. But this does not invalidate the method for its intended domain. It also does not make Dijkstra's ramblings misguided nonsense.

"These days, algorithms are not a major part of most computer systems."

I disagree... While GUI developers don't worry about O(n^2) versus O(n log n) performance, sites like Google wouldn't respond in real time without a focus on the best underlying algorithms.

I agree with the rest of what you say.

How to get a rat out of a maze. http://www.cse.usf.edu/~rtindell/courses/DataStructures/Proj...

On a serious note, you do have a good point. I haven't read much of Dijkstra's work myself.

Well, he didn't derive his algorithm using the approach he advocated, here is what he himself has to say on it:

One morning I was shopping in Amsterdam with my young fiancée, and tired, we sat down on the café terrace to drink a cup of coffee and I was just thinking about whether I could do this, and I then designed the algorithm for the shortest path. As I said, it was a twenty-minute invention. In fact, it was published in ’59, three years late. The publication is still readable, it is, in fact, quite nice. One of the reasons that it is so nice was that I designed it without pencil and paper. I learned later that one of the advantages of designing without pencil and paper is that you are almost forced to avoid all avoidable complexities. Eventually that algorithm became, to my great amazement, one of the cornerstones of my fame. I found it in the early ’60’s in a German book on management science - - “Das Dijkstra’sche Verfahren.” Suddenly, there was a method named after me

Source: http://conservancy.umn.edu/bitstream/107247/1/oh330ewd.pdf