Patterns of Software: Tales from the Software Community

I don't have anything to add to the already glowing reviews of this book other than to say that it is also available on the web at http://www.dreamsongs.com/

This book is one of the best personal commentaries written about the Computer industry as a business and culture that consists of people. Richard Ganriel is best known for his essay "Worse is Better" which is available on the web. "Worse is better" has the Corollary to it that is sometimes more understandable to folks: "if it works then it ain't temporary". This book contains that essay as well as others on Gabriels philosophy on computers, artificial intelligence and other aspects of the field. But the book contains more than just his thoughts and views on the computer field. It also contains a what is calls his "Personal Narrative", an autobiography of himself and how he grew up and why and how he ended as a computer scientist. It also contains the story of the AI startup company he founded in the 1980s Lucid. Lucid, if remembered much today, is because of Lucid Emacs, now XEmacs, which was orginally authored by Jamie Zawinki for Lucid, based on the work of Ricard Stallman and GNU Emacs. Xemacs is the remaining gift that Lucid gave to the computer community. Lucid was a company that pretty much failed, in Gabriels opinion, because of bad management and the "worse is better" hold on the industry, because it had great products that sold. This book, along with the somewhat different "Fire in the Valley" by Michael Swaine and Paul Freiberger. Both explain a lot about the computer industry and how it works, and doesn't work. Building a better mousetrap is not a Guarantee of sucess. Highly recommened book.

There is an excitement in reading what everyone else is afraid to say---and the software world is full of taboos. I passed up "Patterns of Software" a million times in the stores; because of the title, I thought it was yet another book on software Patterns (capital P) in the vein of "Design Patterns" and other recent missives on high-level design.Then I read Richard Gabriel's essay "Worse is Better," available on the web. Though the tone can be bitter and depressing at times, I was immediately hooked on this rare find: a hardcore Lisp person making honest criticisms of both the philosophy and practice of the Lisp world (i.e. academe and the AI industry.) His book is even more rewarding than the essay, because in it Gabriel offers a social theory of software. He explains the overwhelming success and enduring popularity of the C language, but, refreshingly, he does this without taking the easy way out and simply insulting the intelligence of everyone who is not a Lisp user. Gabriel's lessons come from the real world---documented in this semi-autobiographical book---and he didn't always like the answer. While it does discuss Patterns (more deeply and more critically than almost anything else, in my opinion) it is primarily about some common patterns (lowercase p) in the software industry. Such as: why does the "best product" often fail miserably in the marketplace? After the enormous success of UNIX in the 70's and 80's (and the failure of almost everything else) this became an important question. Especially for those who wished to succeed UNIX. Gabriel's answer turns on what has been perhaps been said best by writer Virginia Postrel: "Quality is not one-dimensional." Sadly, Gabriel's book does not include the aforementioned essay on the LISP vs. C dialectic. In it, he opposes two philosophies of software design, which he calls "Worse is Better", and "The Right Thing." The former is a perhaps bitter acknowledgement that the market does not usually reward the perfect product, if for no other reason that what works for some often does not work for others. In line with Postrel's remark, there simply is no single "right thing." The author's writing is deeply conflicted, which makes for an interesting read. The two philosophies cancel each other out, and the software world chose the other one. It's not hard to see why this is so bad for the Lisp community. In the world at large, Lisp has largely lost its special status as "not just another programming language." And when Lisp is seen to have advantages and drawbacks just like everything else, the one-size-fits-all Lisp enterprise itself is thrown into serious doubt. As the author acknowledges, Lisp's mindshare has all but vanished. Faced with the reality of "worse is better", the Lisp world had no answers---and everyone else knew it. I think it is a very honest thing for someone who truly believes in Lisp to question whether its unpopularity is due to something o

I spied this book and picked it up for two reasons: "patterns" and the author. I know something of Gabriel's career through Lucid. He is a certified software wizard. And I was curious if anyone would write something on software patterns that would transcend the obvious and perhaps even find a real tie-in to Alexander's architecture work. And then there was a forward by Alexander. And a tale of Gabriel's rising from failure (or a bad position) again again. Unique. Interesting. So I bought it and I read it one afternoon. There is nothing there for immediate application. No programs. No recipes for overnight success. Just contemplation on how things work. Software. Academia. Industry. And, yes, a bit on life. It does something so few books do. It gives you new perspectives and new questions, and gets you creating new perspectives and asking new questions. It makes you think. At least it did me. One further point. So few in the software field can really write well. Gabriel writes well.

You can't begin with the footnotes, looking for crusty anecdotes: the only one merely is an explanation. You can't directly jump to the index either, aiming at your favorite hottest topic, cross jumping from subjects to keywords, reading paragraphs while thinking you thouroughly read the book: there are only references at the end of the book. And you'd better go through these carefully, to get the taste of what you're about to read: architecture, philosophy, turkish carpets, epistemology, greek wars, biology, style and... management, software engineering and programming languages. Indeed, you may think that a book whose title targets one of the hottest topics in software engineering (one topic eligible for an appearance in the well-known "wired" column --- although it hasn't yet, controversially aligned with something you'd better be "tired" of) should go into the details of the programming and software tricks you need to boost your own project. Well, Richard Gabriel's opus does not. Navigating freely through the essays, you eventually realize Gabriel has a more ambitious vision than teaching his lattest hacking techniques: bridging architecture and software. That is, art and science. Indeed, when stuck with problems in your own field, why not try to learn from other fields? And, in particular, why not try to learn when the words, the processes, the results (and even the failures) so closely echo with those you experience in your day-to-day activity? To achieve such a difficult goal, Gabriel's "Patterns of Software" takes you by the hand, stepping the assembly language of architecture to shed light on that of software. Looking for the realm of beautiful software in the land of beautiful buildings, Gabriel decompiles the work of the architect Christopher Alexander who devoted his life to the realization of beautiful buildings. Gabriel imports architectural notions and concepts (habitability, piecemeal growth, patterns), aiming at a suitable instantiation that would make sotware beautiful as well. Gabriel even finds materials to talk about architectural bugs and spends an essay (titled "the failure of pattern languages") debugging. And in a last reflexive effort, Gabriel decompiles himself, his life, and the company he funded and which later failed, Lucid Inc. But does Gabriel's bridging succeed? You'll wish to end up your journey with the foreword written by Christopher Alexander himself, to agree that the question remains... And that it is not the point. This book is a pioneering brand: neither success nor failure, simply the user guide to go where no programmer has gone before. The reading-risk is to become a software-trekkie. Interested?