This might be premature, but I think I finally understand Dijkstra's approach to deriving programs from post-conditions in "A Discipline of Programming". I've had this book on my bookshelf for almost 20 years, never understood it but also never quite worked up the will to toss it out. (For context, I only own like a dozen books over the long term.)
Concretely, I've made it to the end of Chapter 7. I feel like I understand every bit up until this point.
Parts of Chapter 6 and 7 feel very sloppily written! And this is Dijkstra! So either my leaps of interpretation are only leaps because I'm missing something, or my sense of understanding is an illusion 😅
Has anyone here made it this far and feel like they understood it? I'd love to talk to you.
Incidentally: I wouldn't have made it in even this my probably 4th attempt, if it wasn't for LLMs. They're better than a rubber duck for talking things over with! It's amazing that they can all converse intelligently about the Dijkstra method, and all I need to do is mention wp or wdec . Or I know nothing and am incapable of judging anything about this book.
Hi, Kartik, I'd be very interested in having a conversation about Dijkstra's book. I still have my copy that I ordered as soon as I could after it was published. Working through that book (one works it instead of reading it 🙂) profoundly changed my perspective on programming.
I find it highly ironic that some people who have been critical of formal methods (or even of Dijkstra's style and content) are also proponents of TDD. I have long thought that both ADoP and TDD emphasize using reasoning about correctness as part of the design process (although I continue to believe that Dijkstra's method is potentially more robust, for a variety of reasons).
I'm curious as to what about chapters 6 (designing for termination) and 7 (Euclid's algorithm revisited) left you uncomfortable.
I hope we can connect.
I hadn’t thought about your before-and-after interpretation in quite that way. I’ll have to ponder a bit.
Regarding your reference to determinism, only some constructions in EWD’s wp-based notation are deterministic! While some cases (e.g. x := x-y ) are, EWD’s reasoning makes some kinds of determinism a not-very-interesting special case. The “Aha!” moment for me was his solution for max in c := a max b .
if
a >= b -> c := a
[]
b >= a -> c :- b
fiIn the (again, uninteresting) special case that a = b , both guards are true it is perfectly valid to “perform” either of the two guarded commands.


