Reddit reviews Structured Programming (A.P.I.C. studies in data processing, no. 8)
We found 2 Reddit comments about Structured Programming (A.P.I.C. studies in data processing, no. 8). Here are the top ones, ranked by their Reddit score.
We found 2 Reddit comments about Structured Programming (A.P.I.C. studies in data processing, no. 8). Here are the top ones, ranked by their Reddit score.
I'm pretty sure that the quote is apocryphal. After all, Dijkstra co-authored a book with Dahl and Hoare on "Structured Programming" where the last essay (by Dahl and Hoare) was about Simula 67 and what we now call object-oriented programming. It would have been exceedingly strange for Dijkstra not to have known that OOP originated at the Norwegian Computing Center in Oslo with Simula 67.
You can come back to it later, yes. Why though? You'll need them "now", won't you? I mean, you're going through the book (Skiena's) now, not later. Isn't that right? If you learn it now, you will go through the book better equiped to get its message.
And, besides, it isn't that difficult. It's not trivial by any means. You can try some alternative resources.
I'm not sure why you're interested in deferring this to later. Personally, I believe having seen how proofs of correctness are somewhat done is way more worth it than seeing the algorithms themselves, although some algorithms are pretty educational (like quicksort and also binary search for example). Because even though you won't prove programs correct in practice, knowing how a proof might be devised helps you in writing programs that are easy to prove, and those have to be simple. The whole idea of structured programming that Dijkstra had in mind was to help with this. It's way more intuitive to reason about "while (i < 10) { <do something> }" than a bunch of goto's. In the while-loop case, you can clearly see that upon termination, i >= 10 is true for example. And you can also clearly derive some properties about the body of the loop inductively by analyzing previous iterations.
A lot of good readable code techniques can be put in terms of easy to prove code. Like small functions that do very little, are very cohesive, and work collaboratively. Same for objects. It's way easier to prove correct a bunch of small pieces that work together by some simple means of combination, than a huge big thing.
Good luck.