From: Xah
Subject: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <6tg1bf$o62$1@nntp2.ba.best.com>
> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_2988497061_1101583_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

This is a review of the book _Patterns of Software_, by Richard P. Gabriel
(Oxford Univ. Press, 1996).

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.)

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

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

--

Here's a short 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 of 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 of feelings that it is a
_complete_ waste of time to go further. Thus I have only scanned the last 3
sections in chapter 1 in order to write this review with a moral sense of
completeness. The unintelligibleness of chapter 1 feels like reading Taoism,
except one doesn't see the truism.

--

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:

<begin quote>
* Languages are accepted and evolve by a social process, not a technical or
technological one.

* Successful languages must have modest or minimal computer resource
requirements.

* Successful languages must have simple performance model.

* Successful languages must not require users have "mathematical
sophistication.
<end 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 (e.g. 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 believe 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
 http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/node9.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 an (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,
dinasaurs/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 bulk of the
other half contains the account of misunderstanding technology by an
apparently unsophisticated Paul Zimmer, and a trivial 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 highschool teacher, and how he by hard work and some luck,
went to MIT, UIUC, and lastly obtained a Ph.D. 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-1994, after he obtained his Ph.D. 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 analogy of theory of evolution, and classic examples
like Macintosh vs. PC, success of MicroSoft, Japanese vs. American car
industry...etc. to persuade the reader that worth-is-better is not just
better in practice, but also in theory. The Right Thing philosophy are
categorically condemned as being unfit for survival. This is in fact the
main theme of the whole book. (if there is one.)

--

General Criticism of the book:

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 structure are very complex, without being artful.
Sentences are often much longer than normal. The structure of content is not
easily perceived in paragraphs. In general it is difficult to read. 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 aspects 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 true, 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 remain stronger than
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 a laymen
can be involved in programing. Open a college student's science textbooks,
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 200 centuries of knowledge
in respective fields. If we ignore the hardware parts of computer science,
then it reduces to mathematics. The math for CS is only 50 years old, and
the confusion is understandable. In analogy, the state of physics of ancient
times is as much a science as plumbing in their time.

The author's comments are mainly about human psychology towards software. He
discusses and summarize 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, it is like "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 will be improved, and the
worse-is-better tendency will 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 text editor BBEdit.

-----------------------
(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 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, C is habitable and Lisp is not. In C (or any worse-is-better type
of language), there is a sense of directness. One can copy and paste and
modify with confidence and without concerns for structure. While this is not
so in an abstract or structured setting, which usually requires certain
prerequisites. Thus, for example, C is very habitable and supports piecemeal
growth, while Lisp is not. There is certain sense of holistic outlook here.
_Average_ programer 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 emphasized that he discuss the
horrors of _too much_ abstraction, not abstraction in general. "Oh, Okay.
Swell! Point taken."

Reading "The Quality Without a Name", a tsunami of aversion is flowing
through my veins. 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: <begin quote> "alive, whole, comfortable, free,
exact, egoless,and eternal. I'll go through all of them to try to explain
the quality without a name" <end quote> 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.

 Xah, ···@best.com
 http://www.best.com/~xah/PageTwo_dir/more.html
 Mountain View, CA, USA

--MS_Mac_OE_2988497061_1101583_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Review: Patterns of Software by Richard Gabriel</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
This is a review of the book _Patterns of Software_, by Richard P. Gabriel =
(Oxford Univ. Press, 1996).<BR>
<BR>
I was strongly attracted to the author because of his fame in the Lisp comm=
unity, and because I usually highly value ideas from the Lisp community. Rea=
ding 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 bearin=
gs. Nothing of technical value, and the insights are of dubious or trivial v=
alue.<BR>
<BR>
A bit about the content:<BR>
First of all, this book does not teach the least bit of science or programi=
ng. It is rather an incoherent commentary on several aspects related to soft=
ware, and the author's life stories. The whole book is written in prose styl=
e, containing 0 lines of actual code. If you thought this book is a non-tech=
nical book that one might learn something about the latest programing method=
ologies (as the title might suggest), you are wrong. It is more to the point=
 if the title were &quot;My view and life stories&quot;. (Rather a fit title=
 given the author's fame.)<BR>
<BR>
The book is written (completed) around 1995, as hinted in chapter 5. The bo=
ok is divided into 5 chapters, about 235 pages:<BR>
<BR>
1. Patterns of software.<BR>
&nbsp;Reuse versus Compression<BR>
&nbsp;Habitability and Piecemeal Growth<BR>
&nbsp;Abstraction Descant<BR>
&nbsp;the Quality Without a Name<BR>
&nbsp;Patterns Languages<BR>
&nbsp;the Failure of Pattern Languages<BR>
&nbsp;the Bead game, Rugs, and Beauty<BR>
2. Languages.<BR>
&nbsp;Language Size<BR>
&nbsp;The End of History and the Last Programming Language<BR>
&nbsp;Productivity: Is there a Silver Bullet?<BR>
3. What we do.<BR>
&nbsp;What We Do<BR>
&nbsp;Writing Broadside<BR>
4. Life of the critic.<BR>
&nbsp;A personal Narrative: Journey to Stanford<BR>
&nbsp;A Personal Narrative: Stanford<BR>
5. Into the ground.<BR>
&nbsp;Into the Ground: Lisp<BR>
&nbsp;Into the Ground: C++<BR>
&nbsp;Money Through Innovation Reconsidered<BR>
<BR>
&nbsp;Epilogue<BR>
&nbsp;References<BR>
<BR>
--<BR>
<BR>
Here's a short summary of each chapter. Following that is a review of the b=
ook as a whole.<BR>
<BR>
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 p=
rograming methodologies. In particular, a non-critical criticism on object o=
rientated technologies. It occupies about 40% of the book. 92 pages.<BR>
<BR>
Although this is the largest part of the book, but I think it is also the m=
ost worthless. I did not read the book in order. I started at chapter 2 (bec=
ause it seems most interesting), then 3, 4, parts of 5, then back to 1. By t=
he time I'm reading chapter 1, my enthusiasm of the book has fallen from fan=
atic to almost uninterested. After reading several sections in chapter 1, I =
became so bored and disgusted to the point of feelings that it is a _complet=
e_ waste of time to go further. Thus I have only scanned the last 3 sections=
 in chapter 1 in order to write this review with a moral sense of completene=
ss. The unintelligibleness of chapter 1 feels like reading Taoism, except on=
e doesn't see the truism.<BR>
<BR>
--<BR>
<BR>
Chapter 2 _Languages_ is a 30 pages haphazard comments on some aspects of l=
anguages. Again, it is not a report of some scientific study. It is only the=
 author's thoughts, outlooks, and predictions.<BR>
<BR>
This chapter is roughly an elaboration of the &quot;worse-is-better&quot; p=
hilosophy 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 fl=
ourish. Quote:<BR>
<BR>
&lt;begin quote&gt;<BR>
* Languages are accepted and evolve by a social process, not a technical or=
 technological one.<BR>
<BR>
* Successful languages must have modest or minimal computer resource requir=
ements.<BR>
<BR>
* Successful languages must have simple performance model.<BR>
<BR>
* Successful languages must not require users have &quot;mathematical sophi=
stication.<BR>
&lt;end quote&gt;<BR>
<BR>
I'll briefly go over each. By the author's first criterion, for example, Ja=
va or Perl would be more popular than, say, Dylan or Python. The previous tw=
o are based on widely popular C or Unix tools, making them much easier to ac=
cept than the latter, even if the latter two are technically superior. By th=
e second criterion, for example, C is good because it requires little resour=
ce, while Lisp is bad because it requires large resource (relatively). By cr=
iterion 3, it means that the mathematical model the language is based must b=
e simple. For example, C is the simplest because it is close to assembly, wh=
ile Prolog, Lisp, or Java have complex performance models. By criterion 4, f=
or example, Lisp is very bad because it requires some mathematical sophistic=
ation (e.g. lambda functions, recursions, and so on.). C is good because it'=
s as simple as manipulating beads on an abacus.<BR>
<BR>
I think if we look at the facts, any well-read person will believe that the=
se are good &nbsp;criterions on judging whether a language would be popular =
at present time. However, will they be the characteristics of language popul=
arity in the future? The author believe so, and the chapter's climax predict=
s that C will be the last programing language.<BR>
<BR>
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<FONT=
 SIZE=3D"4"> available on-line at<BR>
&nbsp;http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/node9.htm=
l<BR>
</FONT><BR>
--<BR>
<BR>
Chapter 3 _What we Do_ are divided into two sections. The first section _wh=
at we do_ is only 4 pages. It is an account of an (careless) misunderstandin=
g of technology by Paul Zimmer (supposedly a known figure in the press/writi=
ng community). The relation of this story to the section title is that &quot=
;we&quot; computer scientists should spend more time to explain to the publi=
c what we do. In particular, write books that popularize computer technology=
 for the laymen, in the same sense that there are popularizing books on Frac=
tals/math, Theories of Relativity/physics, stars/astronomy, dinasaurs/archeo=
logy, ...etc. The second section _Writing Broadside_ is also only 4 pages. H=
ere the author, as a &quot;broadside&quot;, encourages computer scientists t=
o improve writing skills. In particular, he emphasized studying poetry and e=
ngaging in writing workshops.<BR>
<BR>
One would expect titles like &quot;What We Do&quot; must contain some non-t=
rivial directions or advice. Instead, out of the meager 8 pages, half of the=
m is the author's peddling of his hobby (writing/poetry), and the bulk of th=
e other half contains the account of misunderstanding technology by an appar=
ently unsophisticated Paul Zimmer, and a trivial provocation for writing mor=
e popularizing books. This chapter failed to convince or persuade me in any =
way. The story of Paul Zimmer seems laughable and unrelated.<BR>
<BR>
--<BR>
<BR>
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.)<BR>
<BR>
This and next chapters seems to be the most valuable of the whole book. Cha=
pter 4 candidly tells how the author grew up in an unimportant town as a poo=
r nobody, missed the chance of going to Havard through an incident with a lo=
usy and nasty highschool teacher, and how he by hard work and some luck, wen=
t to MIT, UIUC, and lastly obtained a Ph.D. Stanford. The writing is touchin=
g with a pessimistic undertone, and many &quot;hackers&quot; in the programi=
ng industry can probably sympathize and identify with. (me, for example.)<BR=
>
<BR>
--<BR>
<BR>
Chapter 5 _Into the Ground_ is the continuation of author's biography, wher=
e he narrates the start and fall of his Lisp company Lucid Inc. in the perio=
d 1981-1994, after he obtained his Ph.D. from Stanford. (33 pages.)<BR>
<BR>
Throughout chapters 4 and 5, the author gives hindsight along the narration=
. In particular in chapter 5, the section _Money Through Innovation Reconsid=
ered_ (13 pages) is a detailed explanation of why worth-is-better is better.=
 The author uses analogy of theory of evolution, and classic examples like M=
acintosh vs. PC, success of MicroSoft, Japanese vs. American car industry...=
etc. to persuade the reader that worth-is-better is not just better in pract=
ice, but also in theory. The Right Thing philosophy are categorically condem=
ned as being unfit for survival. This is in fact the main theme of the whole=
 book. (if there is one.)<BR>
<BR>
--<BR>
<BR>
General Criticism of the book:<BR>
<BR>
We may divide the book into two parts. One is the author's views on softwar=
e 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.<BR>
<BR>
First, about his writing quality.<BR>
We learned from chapters 4 and 5 that the author has strong interest in wri=
ting since teens, and has seriously engaged in writing and poetry writing st=
arting 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 p=
oetry. His writing style is illogical and imprecise, yet failed to be clear.=
 There are illogical (literary) writing styles with exemplary clarity and ex=
cellence, but I judge the book's writings to be very low quality. Sentences'=
 grammatical structure are very complex, without being artful. Sentences are=
 often much longer than normal. The structure of content is not easily perce=
ived in paragraphs. In general it is difficult to read. Ideas and passages a=
re sometimes repeated in sections or in chapters. The arguments are not conv=
incing. One gets the feeling that the author kicked in too much flavor of po=
etry haplessly. The physical aspects of reading of this book has not been a =
pleasant experience.<BR>
<BR>
With respect to the author's views on software methodologies, it appears th=
at he has succumbed to fashionable mediocrity. Instead of pushing for auster=
e mathematics, he talks about what pleases people. Instead of encourage peop=
le 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 (popul=
ar) software/company. If the goal is latter, then much of what he said is tr=
ue, at least at present. That is, language and software should be based on t=
he worse-is-better philosophy, which will result in speed, ease of porting, =
smallness, virus-modeled popularity, and will get people hooked on for perpe=
tual improvements and mutation. Even then, I doubt that worse-is-better phil=
osophy's survivability will remain stronger than The Right Thing in the next=
 10 years. If his goals is (1), then his views are muddled.<BR>
<BR>
There is a saying, that Computer Science (CS) is as much science as fluid d=
ynamics 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 a laymen =
can be involved in programing. Open a college student's science textbooks, i=
t is amazing that the most abstruse facts of nature are explained in perfect=
 detail. Particles smaller than visible light wavelength are measured and cl=
assified, the age of universe is estimated, and abstract ideas in math so ad=
vanced that it takes years of training just to be able to imagine it. It is =
worth noting that each chapter represents 200 centuries of knowledge in resp=
ective fields. If we ignore the hardware parts of computer science, then it =
reduces to mathematics. The math for CS is only 50 years old, and the confus=
ion is understandable. In analogy, the state of physics of ancient times is =
as much a science as plumbing in their time.<BR>
<BR>
The author's comments are mainly about human psychology towards software. H=
e discusses and summarize people's habits in programing, language productivi=
ty 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, it is like &quot;A Study on Cancer Patients with Pets&quo=
t; vs. &quot;New Findings about Cancer&quot;. The only real progress in CS i=
n the long run is by solving math problems. The short term solution is to ed=
ucate programers. Teach them algorithms, algebra, symbolic logic, discrete m=
ath, or even scientific philosophy. Teach them to think independently and lo=
gically, so the quality of the corporate programer as a whole will be improv=
ed, and the worse-is-better tendency will decrease.<BR>
<BR>
If we ask &quot;did he do a good job on the topic as is?&quot;, and my answ=
er would be &quot;No&quot;. In the subject of human psychology to software t=
echnology, there are nobler approaches, in either scientific direction or ob=
servational. The author's comments read like crackpot's. This is especially =
disappointing given the fact that the author has significant training in res=
earch level math and is a prominent figure in CS.<BR>
<BR>
Engineering depends on science. Computer science is a science. Let's not le=
t plumbing muddle it.<BR>
<BR>
&quot;Beware the lollipop of mediocrity. Lick it once and you suck forever.=
&quot; (Footnote 2.)<BR>
<BR>
Footnote 2: The quote is from Rich Siegel's email signature. Author of the =
popular text editor BBEdit.<BR>
<BR>
-----------------------<BR>
(the above concludes my review of the book. What follows are some random ra=
nts on parts of chapter 1 of the book.)<BR>
<BR>
He makes heavy use of analogy of building designer Christopher Alexander's =
criticism in architect 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 go=
es to great effort to explain the parallelism. Scientific principles are pus=
hed aside in favor of new-age style reasoning.<BR>
<BR>
The section &quot;Reuse versus Compression&quot; in chapter 1 expresses the=
 author's opinion that the quality and purpose of inheritance in OOP is bett=
er thought of as &quot;compression&quot; than reuse. This is really a bad ch=
oice of term because &quot;compression&quot; does have a technical meaning i=
n information theory. Even ignoring that, the author's meaning attached to c=
ompression is ill-advised. He thinks compression is a better term because co=
de reuse through inheritance is basically accomplished by a referencing sche=
me, so that classes and instances in lower hierarchy are defined in terms of=
 their parents. Thus, a particular module (class) is merely a _compressed_ w=
ay of writing the module as a stand-along entity. He uses an analogy in poet=
ry to illustrate compression, saying that poetry is an example of compressio=
n. This is inept because the analogy is logically clashing. Poetry is an exp=
ression of human qualities (emotion). The &quot;compression&quot; is at best=
 an effect, not intent. There can be (or exists) poetry that are based on re=
dundancy.<BR>
<BR>
The reason of citing &quot;compression&quot; is never made crispy clear, bu=
t 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 m=
ethod of &quot;compression&quot;.<BR>
<BR>
In &quot;Habitability and Piecemeal Growth&quot;, &quot;Habitability&quot; =
roughly refers to familiarity and comfort. That is, a programing language or=
 paradigm is habitable if it would be comfortable for any _average_ programe=
r to understand and use. It should not require sophistication or abstraction=
. For example, C is habitable and Lisp is not. In C (or any worse-is-better =
type of language), there is a sense of directness. One can copy and paste an=
d modify with confidence and without concerns for structure. While this is n=
ot so in an abstract or structured setting, which usually requires certain p=
rerequisites. Thus, for example, C is very habitable and supports piecemeal =
growth, while Lisp is not. There is certain sense of holistic outlook here. =
_Average_ programer are emphasized, not elite or sophisticates. Comfort and =
naturalness is emphasized. Not established disciplines.<BR>
<BR>
In &quot;Abstraction Descant&quot;, he degrades abstraction through various=
 arguments and out of context quotes. It should be emphasized that he discus=
s the horrors of _too much_ abstraction, not abstraction in general. &quot;O=
h, Okay. Swell! Point taken.&quot;<BR>
<BR>
Reading &quot;The Quality Without a Name&quot;, a tsunami of aversion is fl=
owing through my veins. Here, the _Quality Without a Name_ refers to a quali=
ty without a name. This is where one picks up Zen lessons. What is the _Qual=
ity without a name_? Well, as the name implies, it's self-explanatory. Some =
helpful synonyms would be: &lt;begin quote&gt; &quot;alive, whole, comfortab=
le, free, exact, egoless,and eternal. I'll go through all of them to try to =
explain the quality without a name&quot; &lt;end quote&gt; This _Quality wit=
hout a name_ will be applied to programs. _Perhaps_ you get the idea.<BR>
<BR>
... &quot;Patterns Languages&quot;, &quot;the Failure of Pattern Languages&=
quot;, &quot;the Bead game, Rugs, and Beauty&quot;... Unread.<BR>
<BR>
&nbsp;Xah, ···@best.com<BR>
&nbsp;http://www.best.com/~xah/PageTwo_dir/more.html<BR>
&nbsp;Mountain View, CA, USA<BR>
</BODY>
</HTML>

--MS_Mac_OE_2988497061_1101583_MIME_Part--

From: Bill House
Subject: Re: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <aeSK1.53506$K35.18012041@news.rdc2.occa.home.com>
Xah wrote in message <············@nntp2.ba.best.com>...
>This is a review of the book _Patterns of Software_, by Richard P. Gabriel
>(Oxford Univ. Press, 1996).
>
><major snip>
>

How odd.  You have expended considerable energy to trash this book, yet the
net effect for me has been to make me want to go out and buy it. ;-)

Bill House
From: Justin Forder
Subject: Re: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <mdR0bBAWJD$1EwBq@j-m-f.demon.co.uk>
Bill House wrote in article <························@news.rdc2.occa.hom
e.com>...
>
>Xah wrote in message <············@nntp2.ba.best.com>...
>>This is a review of the book _Patterns of Software_, by Richard P. Gabriel
>>(Oxford Univ. Press, 1996).
>>
>><major snip>
>>
>
>How odd.  You have expended considerable energy to trash this book, yet the
>net effect for me has been to make me want to go out and buy it. ;-)
>
If you care about design, patterns, the state of software engineering,
and the true costs and benefits of hyped technologies, I suggest you do
buy it.

   Justin
-- 
Justin Forder
From: Erik Naggum
Subject: Re: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <3114700816994149@naggum.no>
* "Xah" <···@best.com>
| THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
| this format, some or all of this message may not be legible.

  how true.  but blaming MIME and my mail reader for it is not very nice.

#:Erik, who recommend the book highly
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.
From: Xah
Subject: Re: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <6tj9td$pqb$1@nntp2.ba.best.com>
In article <················@naggum.no> , Erik Naggum <······@naggum.no> 
wrote:

>#:Erik, who recommend the book highly

It would be best if you can write out your reasons or perhaps refute my
review. I'm interested to see alternative reviews. I'm sure other people do
too. If you or anyone know other reviews that is on-line, please let me
know.

The latest version of my review is now at
http://www.best.com/~xah/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.t
xt

>* "Xah" <···@best.com>
>| THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
>| this format, some or all of this message may not be legible.

Erik wrote:
>  how true.  but blaming MIME and my mail reader for it is not very nice.

MicroSoft Outlook Express added that without me knowing it, and that post
was sent out as MIME (or HTML) by mistake.

 Xah, ···@best.com
 http://www.best.com/~xah/PageTwo_dir/more.html
 Mountain View, CA, USA
From: David B. Lamkins
Subject: Re: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <dlamkins-1409981317130001@192.168.0.1>
In article <············@nntp2.ba.best.com>, "Xah" <···@best.com> wrote:

>In article <················@naggum.no> , Erik Naggum <······@naggum.no> 
>wrote:
>
>>#:Erik, who recommend the book highly
>
>It would be best if you can write out your reasons or perhaps refute my
>review. I'm interested to see alternative reviews. I'm sure other people do
>too. If you or anyone know other reviews that is on-line, please let me
>know.

There is a capsule review in the Computer Business & Management section of
<http://www.teleport.com/~dlamkins/computer-books.html>.

-- 
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: Xah Lee
Subject: Re: Review: Patterns of Software by Richard Gabriel
Date: 
Message-ID: <yo37lz4nj3l.fsf@shell13.ba.best.com>
I did some "homework", and found some other reviews of the book and related materials.

Here's a short one:
 http://www.oup-usa.org/docs/0195121236.html

There are about 3 on www.amazon.com also. (just do a search by title)

Here's a undergraduate CS course. It appears that every student has to write an essay on each section of the book. There're plenty "reviews" here.
 http://blackcat.brynmawr.edu/CS/CS245/Materials/

Here's a very well done website about the "patterns" movement.
 http://www.enteract.com/~bradapp/docs/patterns-intro.html

 Xah, ···@best.com
 http://www.best.com/~xah/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
 "patterns" -- another moronic fad.
From: Barry Margolin
Subject: MIME (off-topic was Re: Review: Patterns of Software by Richard Gabriel)
Date: 
Message-ID: <eWaL1.13$yt.201494@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <······@naggum.no> wrote:
>* "Xah" <···@best.com>
>| THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
>| this format, some or all of this message may not be legible.
>
>  how true.  but blaming MIME and my mail reader for it is not very nice.

Is it really necessary to respond to canned text?

Furthermore, it doesn't seem to be "blaming", merely explaining why.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Erik Naggum
Subject: Re: MIME (off-topic was Re: Review: Patterns of Software by Richard Gabriel)
Date: 
Message-ID: <3114784685885039@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| Is it really necessary to respond to canned text?

  in my view _nothing_ rates as "really necessary", but I guess it _is_
  really necessary for _you_ to debate the bloody obvious.  however, a
  little thinking about your own desire to comment on such things _might_
  shed some light on the multitude of reasons that drive others to respond
  even if you don't enjoy the humorous relation between a canned apology in
  front of a message illegible in many _more_ ways than just MIME.

  please consider whether it is "really necessary" to respond.  thank you.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.