Software Tools

First, I don't have to reintroduce how awesome the author (especially bwk) is. I will just jump to the main topic. This book, by any means, is better than Code Complete(CC). Don't get me wrong, I am not saying CC is a bad book. To the contrary, CC is a very good book. But this book is still better. Why, here are three reasons. 1. CC is motivated by this book, Software Tools(ST). If you read carefully, you will find that in the preface of CC, it says that "No comparable book is available... some had written 15 years or more earlier ... in Ratfor". Tell you want, it refers to this book(ST). ST deserves a better position than "a 15 years old book in Ratfor", because it handles a even wider topic than CC: how to build practical software. Thus, if you like CC, I will recommend you to this book. If you think CC is verbose, bingo, you have a better choice: this book. 2. ST talks every almost every aspect of programming and tells you how to build into the programming language instead of in the programming language. Think about this, in the FORTRAN years, how to write software not only conquer the complexity of the outside world, but the complicity of the programming language itself. There are tons of books teaches you do Design Pattern, structured programming etc. However, there is no book about how you use your programming language to achieve that. Think about this, JUnit is handy in Java; OO language is handy because they don't need damn pointers around, dynamic type language is handy because you don't need verbose SomeType a = New SomeType() statement. Hardly, you can not find all favorite features in YOUR language. YOUR language usually sucks. (So as mine). There is no silver bullet language. Then, ST teaches you how to use your language to build clean and useful blocks and then get things done. You will finally realize languages will never be your obstacle and you can "import antigravity" to fly (a inner joke, see http://xkcd.com/353/ ). There are two kinds of book, one is by theoretical authors and the other is by the real software engineers. The first kind of book will teach you all kinds of checklist/dogma but you never know how they get used in reality. The second kind of book is like a manual or a tutorial, you can follow it and know what is "structured programming" by practicing it, instead of by "memorizing" it. My kongfu master once told me that you have to learn by acting, not learn by reciting a book. 3. The philosophy in ST is even more valid today, which makes this book even more useful. Think about this, 20 years ago, in Bell Lab, bwk was building C/Unix. His experience was that human time is far more expensive than machine time (He is a scientist) and software should be flexible and code should be readable because you will definitely read it. The experience from Bell Lab is exactly the situation today. (you know, they lead the industry by 20 years, for sure). Human time are far more expensive than machine time and software are

I read this book about 20 years back. And I keep quoting it and recommending it, and re-reading it. This is because it changed my whole perspective about writing software. Let me share the two big lessons I learnt. The first was ego-less programming. Sharing the code and encouraging feedback. We applied this in our group with amazing results. It is a valuable lesson because it is so tough to implement - because of our ego. The big one was about not writing applications but tools. And creating applications from tools. This lesson kept haunting me whenever I wrote any program. It helped me write generic programs that could be re-used. The Ratfor examples are a bit dated now. But they elegant and pure. A must read for all aspire for excellence in coding software.

The tools you will find in this book are ancient. They're written in a cockeyed hybrid of C and Fortran, and they're almost hilariously user-hostile by modern definitions. If this intimidates you, look at it this way -- you're looking under the hood of modern applications. Much modern word processing, page layout, and language implementation can be built by putting a nice, shiny coating on what you find in this book.Kernighan and Plauger set out in this book to document what they used in their labs at the time it was written, and show how to build them. Ratfor was chosen because C was not as widespread then as it is now, and for those who didn't have it, a translator to standard Fortran '77 was one of the major parts of the book. A simplified version of the nroff text formatter and a version of ed are also included for text file processing (then as now one of the major uses for computers), the result being both a toolkit and a practical education in the ins and outs of applications development.The environment given is not Unix-based inherently, but this book is a natural companion to Kernighan and Rob Pike's The Unix Programming Environment and John Lions' Commentary on Unix 6th Edition. It should be required reading for anyone who wants to do software development.

Software Tools. I can't say enough about how important this book was - and still is - to me. The Software Tools in Pascal version does not have the same effect - it doesn't really work. But Software Tools gets across the idea that you do not have to accept the constraints of your environment to produce excellent programs. Instead, develop the program the way is should be and make a surprisingly small effort to then map it to your environment. Don't let the environmental problems constrain your thinking or actual programming. Then with a little effort you can get your environment to match what you need. The book develops a series of software tools, unix style commands, but implements them in a language called RATFOR (Rational Fortran). This is done because Fortran IV was universal at the time, but also horrible as a structured programming language. The delima: Use a better but less widely available language, or use a horrible but very popular and standard language. The author's choice - and the philosophy of the book - don't be boxed in by this choice. They added to Fortran the structures found in C and then wrote a preprocessor to translate this RATFOR to Fortran. The end result was the best of both worlds: well structured programs that will run on just about anything. The whole book is about this kind of choice. It is great philosophy for software development and great philosophy for life. END