Available at http://catb.org/~esr/writings/taoup/h...

I wanted to love this book, but INSTEAD I just sort of liked it. The book definitely was not a bad read, but it did not fit my needs.

This book is more about the learnings/lessons from Unix world. Mostly historical descriptions and why certain choices were made by Unix and how they were revolutionary as compared to other operating systems. Lots of practice case studies are included wherein how and why certain choices were made by certain popular programs were made.A very quick read for me - more of like a refresher -as I was already well versed with the historical developments.

An excellent book, although I think the title is badly chosen because it's a bit of a misnomer and could put people off: the title implied to me that it would be about how to code for UNIX, what it *actually* is is the philosophies and design decisions that have influenced UNIX and why they were made. I think you could read this book without being a programmer and still get something out of it, however I also think that some familiarity of common UNIX tools would help as a number of them are use...

Good book. There were a lot of things in here that I've felt for a long time but was not sure how to explain. For example, the discussion of why config files should be human readable made me realize why I was so opposed to an advisor's suggestion that our config file be a giant ugly s-expression on a project I did last year; it also made me realize why I felt that the backend for that project should use sockets to communicate with the GUI (because it encourages modularity, keeps GUI code out of

The book includes an overview of core Unix principles and philosophies, such as:Rule of modularity - write simple parts connected by clean interfacesRule of clarity - clarity is better than clevernessRule of composition - design programs to be connected with other programsRule of separation - separate policy from mechanism; separate interfaces from enginesRule of simplicity - design for simplicity; add complexity only where you mustRule of parsimony - write a big program only when it is clear by...

There are lots of wisdom in the book, The information in the book is relevant today. The discussions about tools, such as sed, cat, awk are interesting since he says they have survived the trial of time, 17 years later and still in use. Vi and Emacs are two editors that survived the trial aswell.In the end, the aspect of developing tools for non-developers is still a struggle today. For example, Jenkins is a high performance and the GUI leaves lots of things to wish for. Not that it was an examp...

If you're into stuff like this, you can read the full review.Elegance Personified: "The Art of UNIX Programming" by Eric S. Raymond(Original Review, 2003-02-13)My two cents on Unix, C, Gates, Ritchie, Jobs, Apple OS, Windows, C++, Objective-C, Java, BSD, ...The toe curling pieces on Jobs were way over the top, rather like Gates, Jobs lifted a lot from other people. Ritchie and co, rather like Tim Berners-Lee, gave the computing world so much, and I do mean gave (let’s not be offensive, not equat...

WIP, will review later

Victory!!! I have finally completed this book. The book weighs in at just under 500 pages, but it reads much longer than that (at least for me) I don't want to imply that that is negative though, the book is wonderful, and is an absolute must read for any software developer. It just took me 3 months to read, which is significantly longer than I would have thought, or originally wanted.This book does a very good job of explaining the culture and history of unix, but all of those cultural and hist...

An extended argument for the genius of UNIX.

This book is a CS classic. Now, as more than a billion computers (ie /servers/smartphones/notebooks) run a Linux operating system, software running Unix derivates is ubiquitous. That was not the case when this classic book was written in 2003. The original creators of the Unix operating system reflect on the design decisions they made in the 1970s, 80s and 90s as well as the underlying philosophy that guides the suite of software tools running on Unix (now eclipsed by Linux). These deliberate, a...

While dated (published in 2003), this book covers a large amount of relevant history that help explain *why* Unix is the way it is. I lived through about half the history that was covered and experienced about a decade and a half. Despite being a professional programmer for twenty years, I felt like I learned a lot from this book. While I have heard most of the Unix programming maxims before, this book really filled in the history and reasoning behind the sayings. I think this would be a valuabl...

Wonderful book in my opinion. It really tells you why Unix (and Linux) are the way they are and the efforts that made it become what it is. To me, Linux is a great humanity achievement.This book is technical without being technical, it really is about philosophy and principles rather than algorithms, syntax or other programming techniques. Could be seen as an encyclopedia.

Enjoyable insight into some history of the UNIX world.

This book is about programming. Still, there is almost not a single snippet of code in this 500 page book. Instead it focuses on the philosophy that has developed within the UNIX community over the years. There is a lot of knowledge to be found here, even if you don't develop for, or even like UNIX systems. It has got comments from early UNIX hackers, even some of the original creators, which enrich the text and gives a broader perspective on things in some cases.The fact that many sections incl...

The history section alone is worth it. Nathan Marz's mantra of "first make it possible, then make it beautiful, then make it fast" clearly were taken from this philosophy. A nearly identical mantra is stated in the first pages of this book.History is doomed to repeat itself.I first read the chapter on Textuality, and have since gone back and started from the beginning. So far this book is excellent.

It's a dense book with a brief tour trough the pre historical unix and many aspects regarding the good practices involved in developing software the unix way. I'm sure I didn't absorbed everything that was shown, but I'm sure I got really good insights that would help me to become a better developer. I'll have to read it again somehow in the future, and certainly I'll be able to take more from it.

Curiously Raymond managed not to read Gancarz's classic The Unix Philiosophy while writing this. It doesnt cover quite the same ground, and is much less concise. Its bigger on scripting languages and other more recent developments.

Great book albeit quite biased against Microsoft and looks down on all other software/OSes. The last chapter offers some critical reflection on this pride.I really enjoyed the software-related discussions on design and implementation methodologies. The talk of transparency and discoverability being critical to ease of software maturity and usage.The book's age however shows in the dead links and outdated sections (e.g. on JavaScript, web browsers etc.).Great read though and full of wisdom.