Customer Reviews

A Discipline of Programming

5 star:		(5)
4 star:		(2)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

---

Coming from no less a person than Dijkstra, this book, though dated takes programming to a different level.

It blesses the discipline of programming with the mathematical formalism and begins to look at it as a piece of mathematics.

I picked this book while doing my CS undergraduate, and made me fall in love with CS, all over again.

It does NOT however talk much about programming techniques or methods! It looks at programs from as formal a view point as possible and builds a framework for constructing 'correct' programs..or more correctly a framework for 'proving the correctness' of a program. It takes you to the point of considering programs as poetry..

Its difficult to contemplate the application of the thoeries developed here into practice, though a lot of it is used in some form or the other, but nonetheless it makes an excellent reading.

I recommend it to anybody seriously interested in computer science .

I purchased A Discipline Of Programming about fifteen years ago, at the start of my programming career. It remains the most important programming book that I own, and possibly the most important book of any kind. Anyone who aspires to be a programmer should spend many hours reading it. It is impossible not to benefit hugely.

The (unnamed) language invented by Dijkstra, almost as an aside in the early chapters of the book, is the language in which I would most like to write my programs. Some day perhaps I will be able to.

This is not only a book about programming, it is also a book about reasoning on programs, and even a book about reasoning. Treating a program as a formal object, the book discussed its meaning, how to reason about it, and even how to derive it. If you are not a hacker or do not want to be one, you will like this book, and highly possiblely you will read it many times.

This book shows by example that iterative algorithms can be derived - you don't need a lucky inspiration to discover them. If you have ever vacillated between putting something in the initialization or body of a loop; or written a loop that doesn't terminate in some cases; this will change your whole approach to coding.

I still have my original copy of this book. It is one of thefew that are not in storage.

Many of the concepts (such as the chapters on arrays and verification) are still fresh. The emphasis on developing programs by stepwise refinement has guided much of my own programming...

I really wanted to get my hands on this book and now that i have (via interlibrary loan) i want to warn folks that this is not light reading. I found a majority of this book very boring and all but impenetrable. I like Dijkstra's English prose, but when he embarks on the math I wish he'd state the point of each set of formulae above them. It would have also helped if he stressed practical uses of his insights vis-a-vis an actual programming language. This "just shows how much I know" I'm sure, but I suspect many people will feel similarly. FYI: My background is Bachelor's in C.S. with a C.S. GPA of 3.87/4.0. A depressing indictment of U.S. education, Dijkstra would say :)

This is an excellent book in reasoning about programs. It is fairly rigorous and requires a bit of math maturity, and the reader should be warned that formal methods of computer science have evolved quite a bit since 1976. By this I refer to axiomatic program verification and semantics. The key characteristic of this book is that it is built around discussing real world algorithms. This makes the practical consequences of the analysis more evident than in a typical textbook format.

It was strongly "suggested" to me in one of my early microcomputer programming jobs that I read two books to advance my skills - this book and the "Tao Te Ching" of Lao Tzu. Of the two books, the Tao was far more useful.

I spent months in 1981, (yes months!) working through the chapters of Discipline, only to be told by my boss, finally, that he too had had similar experiences with it and that its usefulness was only in being aware that such methods existed, being aware of the considerations and reasonings in it. This same boss became my most difficult taskmaster, but my mentor in the 4 years I worked for him. It was through him that I made the transition from average run of the mill programmer to expert software engineer.

Dijkstra's book is mis-titled "A Discipline of Programming" - this title points immediately to a fundamental flaw of the book. It suggests, no actually makes claims, that it will depict a system, a formalism, a scientific method of developing programs for average working programmers, something that we have all dreamed of. But that is not at all what it is. It is, in fact, a book with the pretension and advertised claim that if we master its formalism methodology of program development by weakest precondition considerations, enumerations and deductions we will have a formal symbolic logic tool which will literally generate, on paper, the body of the algorithm needed to accomplish the desired task. In point of fact, such a mechanisitc approach might be, and probably is of interest to computer scientists doing research in, for example, machine generation of programs or related areas. If Dijkstra's claims are true, and he does give some beautifully worked out examples, easily translatable to C code, then the title of the books should have been something like "A Straightjacket of Programming". But I believe the correct title for this book should have been, even though it would probably have sold far less copies, "A Discipline of Computer Science".

I can still like the book and look in awe on the "discipline" that generated the solutions to the problems he shows. But there is too much wrong with the book to allow its seduction to supersede reason. He uses some non-standard logical formalism constructions, barely noting this in passing. In fact, you really need the second book, written no doubt in responds to agonized requests for more details of the "discipline", by David Gries, "A Science of Programming" (far better title by the way, too) in order to fully understand the details of Dijksktra's goals, mode and modus.

Dijkstra anticipates my objection and even give a nice example involving database updates to counteract my criticism but alas, it is not nearly enough, to seriously question the applicability of the methods of his book, now looking a little dated, to the modern programmer or software engineer.

Bottom line - brilliant author, iconoclastic, but unaware apparently that programming is part art, part science, just like being a Doctor or a physicist. Nothing in life is generated in the manner Dijkstra suggests unless one happens to be a mathematician doing formal proofs, a robot, or AI program, the only entities to which this book should have been addressed other than researchers building such things. In 32 years of software, I've known only a few Bell Telephone engineers who used the method on occasion and by now they've probably forgotten it too.

I have no use for Dijsktra's thinly veiled contempt for those who do not or worse, will not use his "discipline" nor for his contempt for other languages that do not fit his particular taste. He constantly hints in all his writings that he has the magic touchstone, the holy grail, that will obviate the necessity of coding "monkeys" and those deep in the trenches of real world problems and I learned, the more experience I obtained, to not believe a word of it. In some of the projects and time constraints I worked on Dijkstra would not have lasted 10 days and it is I who have contempt for him and his ivory tower nonsense and attitudes, the same sort of attitudes which in the early days of programming turned the mainframe into almost an altar which required mathematical sanctification of all those who dared approach it - utter nonsense akin to the pay and benefits unfair treatment of women in the field back then. Like all of us he worked out a method that works for HIM. It can be copied and used and no doubt a few do this, but in reality, we all develop our own techniques and approaches. To tout any one of them as universally the "answer" is absurd.

Not without value and for students and computer scientists a good book, a great book. But practical? Just ask some software engineers working on REAL projects how many use these formalisms and generative approaches - in projects that really get finished, really work, on time and under budget.
It's like someone writing a book entitled "A Discipline of Calculus" and then claiming that every engineer should use it to "properly" develop their projects, allowing the formalism to do their thinking for them. I don't know about you, but I'm not sure I'd want to drive over a bridge designed that way. Verazzano Narrows anyone?

I found this book interesting - not least because it is a "classic" computing text. It seems like (I can't be more definitive because I have never studied computer science) an introduction to thinking about proving programs correct and reasoning about code.

I wouldn't recommend it to someone learning computing - it's hardly Abelson et al. - but it's a good book to muse over.