Book Review: Patterns of Software

By Xah Lee. Date:

This is a review of the book Patterns Of Software By Richard P Gabriel. Buy at amazon

Summary

I was strongly attracted to the author because of his fame in the Lisp community, and because I usually highly value ideas from the Lisp community. Reading this book is one big disappointment. In two sentence summary: the book appears to be an old crank's rambling on software issues and personal bearings. Nothing of technical value, and the insights are of dubious or trivial value.

A bit about the content: First of all, this book does not teach the least bit of science or programing. It is rather an incoherent commentary on several aspects related to software, and the author's life stories. The whole book is written in prose style, containing 0 lines of actual code. If you thought this book is a non-technical book that one might learn something about the latest programing methodologies (as the title might suggest), you are wrong. It is more to the point if the title were “My view and life stories”. (Rather a fit title given the author's fame.)

Book Table of Contents

The book is written (completed) around 1995, as hinted in chapter 5. The book is divided into 5 chapters, about 235 pages: 

Introduction (by Christopher Alexander)
Preface

1. Patterns of software.
   Reuse versus Compression
   Habitability and Piecemeal Growth
   Abstraction Descant
   the Quality Without a Name
   Patterns Languages
   the Failure of Pattern Languages
   the Bead game, Rugs, and Beauty
2. Languages.
   Language Size
   The End of History and the Last Programming Language
   Productivity: Is there a Silver Bullet?
3. What we do.
   What We Do
   Writing Broadside
4. Life of the critic.
   A personal Narrative: Journey to Stanford
   A Personal Narrative: Stanford
5. Into the ground.
   Into the Ground: Lisp
   Into the Ground: C++
   Money Through Innovation Reconsidered

   Epilogue
   References

Chapters Summary

Here is a short commented summary of each chapter. Following that is a review of the book as a whole.

Chapter 1 Patterns of software is the most relevant to programing of the whole book. Basically, it is a series of commentaries on issues related to programing methodologies. In particular, a non-critical criticism on object orientated technologies. It occupies about 40% of the book. 92 pages.

Although this is the largest part of the book, but I think it is also the most worthless. I did not read the book in order. I started at chapter 2 (because it seems most interesting), then 3, 4, parts of 5, then back to 1. By the time I'm reading chapter 1, my enthusiasm for the book has fallen from fanatic to almost uninterested. After reading several sections in chapter 1, I became so bored and disgusted to the point that I decided it is a _complete_ waste of time to go further. Thus, the last 3 sections in chapter 1 I have only scanned in order to write this review with a moral sense of completeness. The unintelligibleness of chapter 1 feels like reading Taoism, except that the truism isn't there.

Chapter 2 Languages is a 30 pages haphazard comments on some aspects of languages. Again, it is not a report of some scientific study. It is only the author's thoughts, outlooks, and predictions.

This chapter is roughly an elaboration of the “worse-is-better” philosophy explained in his earlier publication (see footnote 1 below) except that the author this time meant it literally without sarcastic undertone. I'll give an example of the chapter's theme, so readers not familiar with the term may get some idea. The author lists four elements for a language to flourish. Quote:

I'll briefly go over each. By the author's first criterion, for example, Java or Perl would be more popular than, say, Dylan or Python. The previous two are based on widely popular C or Unix tools, making them much easier to accept than the latter, even if the latter two are technically superior. By the second criterion, for example, C is good because it requires little resource, while Lisp is bad because it requires large resource (relatively). By criterion 3, it means that the mathematical model the language is based must be simple. For example, C is the simplest because it is close to assembly, while Prolog, Lisp, or Java have complex performance models. By criterion 4, for example, Lisp is very bad because it requires some mathematical sophistication (For example, lambda functions, recursions, and so on.). C is good because it's as simple as manipulating beads on an abacus.

I think if we look at the facts, any well-read person will agree that these are good criterions on judging whether a language would be popular at present time. However, will they be the characteristics of language popularity in the future? The author believe so, and the chapter's climax predicts that C will be the last programing language.

Footnote 1: The keynote address _Lisp: Good News, Bad News, How to Win Big_ is given by the author in 1990 at the European Conference on the Practical Applications of Lisp, and reprinted in several computer journals. It is available on-line at author's home page: http://www.dreamsongs.com/WIB.html

Chapter 3 What we Do are divided into two sections. The first section _what we do_ is only 4 pages. It is an account of a (careless) misunderstanding of technology by Paul Zimmer (supposedly a known figure in the press/writing community). The relation of this story to the section title is that “we” computer scientists should spend more time to explain to the public what we do. In particular, write books that popularize computer technology for the laymen, in the same sense that there are popularizing books on Fractals/math, Theories of Relativity/physics, stars/astronomy, dinosaurs/archeology, etc. The second section _Writing Broadside_ is also only 4 pages. Here the author, as a “broadside”, encourages computer scientists to improve writing skills. In particular, he emphasized studying poetry and engaging in writing workshops.

One would expect titles like “What We Do” must contain some non-trivial directions or advice. Instead, out of the meager 8 pages, half of them is the author's peddling of his hobby (writing/poetry), and the other half contains the account of a frivolous misunderstanding as a provocation for writing more popularizing books. This chapter failed to convince or persuade me in any way. The story of Paul Zimmer seems laughable and unrelated.

Chapter 4 Life of the Critic is a short autobiography of author's life in academy from teens to up to about age 30. (23 pages.)

This and next chapters seems to be the most valuable of the whole book. Chapter 4 candidly tells how the author grew up in an unimportant town as a poor nobody, missed the chance of going to Havard through an incident with a lousy and nasty high school teacher, and how he by hard work and some luck, went to MIT, UIUC, and lastly obtained a Ph.D. at Stanford. The writing is touching with a pessimistic undertone, and many “hackers” in the programing industry can probably sympathize and identify with. (me, for example.)

Chapter 5 Into the Ground is the continuation of author's biography, where he narrates the start and fall of his Lisp company Lucid Inc. in the period 1981 to 1994, after he graduated from Stanford. (33 pages.)

Throughout chapters 4 and 5, the author gives hindsight along the narration. In particular in chapter 5, the section Money Through Innovation Reconsidered (13 pages) is a detailed explanation of why worth-is-better is better. The author uses classic examples like Macintosh vs PC, success of Microsoft, Japanese vs American car industries… and analogy to theory of evolution to persuade the reader that worth-is-better is not just better in practice, but also in theory. The Right Thing philosophy is categorically condemned as being unfit for survival. This is in fact the main theme of the whole book. (if there is one.)

General Criticism

We may divide the book into two parts. One is the author's views on software engineering issues, the other is his biography. The value of the second is intrinsic, thus it needs not be assessed. I'll focus on his views, and the overall quality of the book.

First, about his writing quality. We learned from chapters 4 and 5 that the author has strong interest in writing since teens, and has seriously engaged in writing and poetry writing starting on 1992. (he was born on 1949) Throughout the book, the author freely makes analogies to poetry to make a point. Clearly, he is infatuated with poetry. His writing style is illogical and imprecise, yet failed to be clear. There are illogical (literary) writing styles with exemplary clarity and excellence, but I judge the book's writings to be very low quality. Sentences' grammatical structures are very complex without being artful. Sentences are often much longer than normal. The structure of content is not well-organized by paragraphs. Ideas and passages are sometimes repeated in sections or in chapters. The arguments are not convincing. One gets the feeling that the author kicked in too much flavor of poetry haplessly. The physical aspect of reading of this book has not been a pleasant experience.

With respect to the author's views on software methodologies, it appears that he has succumbed to fashionable mediocrity. Instead of pushing for austere mathematics, he talks about what pleases people. Instead of encourage people to study more math and science, he goes the other way around, saying that languages and methodologies should not be based on math but to suit average programer's intellects. It is not clear to me which goal he has in mind: (1) To enrich and improve people's lives (for both programer and user) in the general sense as a contribution to human kind. (2) To make successful (popular) software/company. If the goal is latter, then much of what he said is sensible, at least at present. That is, language and software should be based on the worse-is-better philosophy, which will result in speed, ease of porting, smallness, virus-modeled popularity, and will get people hooked on for perpetual improvements and mutation. Even then, I doubt that worse-is-better philosophy's survivability will beat The Right Thing in the next 10 years. If his goals is (1), then his views are muddled.

There is a saying, that Computer Science (CS) is as much science as fluid dynamics in plumbing. Today we have so much confusion in computer science is partly due to the infancy of the field, and partly due to the ease for laymen to entry. Open a college student's science textbook, it is amazing that the most abstruse facts of nature are explained in perfect detail. Particles smaller than visible light wavelength are measured and classified, the age of universe is estimated, and abstract ideas in math so advanced that it takes years of training just to be able to imagine it. It is worth noting that each chapter represents 2000 years of knowledge. If we ignore the hardware part of computer science, then it reduces to mathematics. The math for CS is only 50 years old. The confusion is understandable. In analogy, the state of physics of ancient times is as much a science as plumbing in their time. On the other hand, it is very likely that CS 50 years from today will be so advanced to be barely recognizable.

The author's comments are mainly about human psychology towards software. He discusses or summarizes people's habits in programing, language productivity statistics, preference of syntax, small vs large languages, pitfalls of object oriented programing…etc. These issues are of superficial nature in CS. As an analogy, compare: “A Study on Cancer Patients with Pets” vs “New Findings about Cancer”. The only real progress in CS in the long run is by solving math problems. The short term solution is to educate programers. Teach them algorithms, algebra, symbolic logic, discrete math, or even scientific philosophy. Teach them to think independently and logically, so the quality of the corporate programer as a whole can be improved, and the worse-is-better pest can decrease.

If we ask “Did he do a good job on the topic as is?”, and my answer would be “No”. In the subject of human psychology to software technology, there are nobler approaches, in either scientific direction or observational. The author's comments read like crackpot's. This is especially disappointing given the fact that the author has significant training in research level math and is a prominent figure in CS.

Engineering depends on science. Computer science is a science. Let's not let plumbing muddle it.

“Beware the lollipop of mediocrity. Lick it once and you suck forever.” (Footnote 2.)

Footnote 2: The quote is from Rich Siegel's email signature. Author of the popular Macintosh text editor BBEdit.

Criticism on Chapter 1

The above concludes my review of the book. What follows are some random rants on parts of chapter 1 of the book.

He makes heavy use of analogy of building designer Christopher Alexander's criticism in architect engineering to software engineering. This parallelism is employed fanatically, where Alexander's every principle and ideas in building design are forced to have a counterpart in software engineering. And the author goes to great effort to explain the parallelism. Scientific principles are pushed aside in favor of new-age style reasoning.

The section “Reuse versus Compression” in chapter 1 expresses the author's opinion that the quality and purpose of inheritance in OOP is better thought of as “compression” than reuse. This is really a bad choice of term because “compression” does have a technical meaning in information theory. Even ignoring that, the author's meaning attached to compression is ill-advised. He thinks compression is a better term because code reuse through inheritance is basically accomplished by a referencing scheme, so that classes and instances in lower hierarchy are defined in terms of their parents. Thus, a particular module (class) is merely a _compressed_ way of writing the module as a stand-along entity. He uses an analogy in poetry to illustrate compression, saying that poetry is an example of compression. This is inept because the analogy is logically clashing. Poetry is an expression of human qualities (emotion). The “compression” is at best an effect, not intent. There can be (or exists) poetry that are based on redundancy.

The reason of citing “compression” is never made crispy clear, but it seems to be a support of his argument that OOP's promise of reusability is at best not a complete solution, because it is actually more or less a method of “compression”.

In “Habitability and Piecemeal Growth”, “Habitability” roughly refers to familiarity and comfort. That is, a programing language or paradigm is habitable if it would be comfortable for any _average_ programer to understand and use. It should not require sophistication or abstraction. For example, in C, there is a sense of directness: codes can be copy-pasted or modified with confidence and without concerns for screwing up other parts (because there's little structure). While this is less so in an abstract or structured setting, which usually requires certain prerequisites (computing model or architect of the project). Thus, C is very habitable and supports piecemeal growth, while Lisp is not. There is certain sense of holistic outlook here. _Average_ programers are emphasized, not elite or sophisticates. Comfort and naturalness is emphasized. Not established disciplines.

In “Abstraction Descant”, he degrades abstraction through various arguments and out of context quotes. It should be noted that he emphasized the horrors of _too much_ abstraction, not abstraction itself. “Oh, Okay. Swell! Excessive goodness is bad too.”

Reading “The Quality Without a Name”, a tsunami of aversion is flowing through my vein. Here, the _Quality Without a Name_ refers to a quality without a name. This is where one picks up Zen lessons. What is the _Quality without a name_? Well, as the name implies, it's self-explanatory. Some helpful synonyms would be: (quote from the book) “alive, whole, comfortable, free, exact, egoless, and eternal. I'll go through all of them to try to explain the quality without a name”. This _Quality without a name_ will be applied to programs. _Perhaps_ you get the idea.

… “Patterns Languages”, “the Failure of Pattern Languages”, “the Bead game, Rugs, and Beauty”… Unread.

Postscript

In the back of the book, there are 4 quotes supposedly from other reviews. I'll take the liberty to reproduce them here:

“Entertaining and insightful.” —Journal of Object-Oriented Programming

“Gabriel is an illuminating guide, providing fresh and invigorating perspectives guaranteed to stick with you long after you boot up.” —San Francisco Sunday Examiner and Chronicle

“Lucid and stimulating.” —Daily Telegraph (London)

“This is a clear, insightful book that takes an alternative look at some of the broader issues surrounding software development.” —Sanjiv Gossain, Associate Director, Cambridge Technology Partners

If you read between the lines, these are not exactly praises for a Nobel-prize class book. Favorable, to be sure. I wonder to what extent a prominent figure have pressure or psychological influence on his reviewers.

It is tempting to speculate how a founder of Common Lisp and a respected expert in AI could have written such a trashy book. (not counting the autobiography part) Perhaps the book is hastily written as hinted in the Preface. Perhaps I inappropriately expected to learn something technical and specific from the book. As I reread the Preface, it is possible to infer that the author intend the book to be no more than a rambling from an old cynic. I hope it is true, that this book is a mere negative outpouring of one's life-long frustrations, and that deep in Dr. Gabriel's heart he is still a proponent for The Right Thing.

A common reaction to my review was that: If it is so bad, why write such an elaborate review? I wrote it spontaneously. My motivations are probably: as a writing exercise, boredom, want to broadcast my hatred for the book (especially so because I had a high esteem for the author and I'm a cynic myself.) A few notes turned into paragraphs turned into a full review with my own opinions that were buried in me for long.

© 1998 by Xah Lee. This document may be distributed freely provided that it is distributed in whole and not modified in any way.

addendum: the whole book is now available free on Richard P Gabriel's website http://www.dreamsongs.com/ pdf at PatternsOfSoftware.pdf