info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Review: Patterns of Software by Richard Gabriel
76 views
Skip to first unread message
Xah
Sep 13, 1998, 3:00:00 AM9/13/98
to
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, x...@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
Mountain View, CA, USA
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, x...@best.com
http://www.best.com/~xah/PageTwo_dir/more.html
Mountain View, CA, USA
Bill House
Sep 13, 1998, 3:00:00 AM9/13/98
to
Xah wrote in message <6tg1bf$o62$1...@nntp2.ba.best.com>...
>This is a review of the book _Patterns of Software_, by Richard P. Gabriel
>(Oxford Univ. Press, 1996).
>
>
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
Erik Naggum
Sep 13, 1998, 3:00:00 AM9/13/98
to
* "Xah" <x...@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.
| 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.
Justin Forder
Sep 13, 1998, 3:00:00 AM9/13/98
to
Bill House wrote in article <aeSK1.53506$K35.18...@news.rdc2.occa.hom
e.com>...
and the true costs and benefits of hyped technologies, I suggest you do
buy it.
e.com>...
>>This is a review of the book _Patterns of Software_, by Richard P. Gabriel
>>(Oxford Univ. Press, 1996).
>>
>>(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,>>
>
>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. ;-)
>
and the true costs and benefits of hyped technologies, I suggest you do
buy it.
Justin
--
Justin Forder
Xah
Sep 14, 1998, 3:00:00 AM9/14/98
to
In article <31147008...@naggum.no> , Erik Naggum <cle...@naggum.no>
wrote:
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" <x...@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.
Barry Margolin
Sep 14, 1998, 3:00:00 AM9/14/98
to
In article <31147008...@naggum.no>, Erik Naggum <cle...@naggum.no> wrote:
>* "Xah" <x...@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.
>
>* "Xah" <x...@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, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Erik Naggum
Sep 14, 1998, 3:00:00 AM9/14/98
to
* Barry Margolin <bar...@bbnplanet.com>
| Is it really necessary to respond to canned text?
| 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
David B. Lamkins
Sep 14, 1998, 3:00:00 AM9/14/98
to
In article <6tj9td$pqb$1...@nntp2.ba.best.com>, "Xah" <x...@best.com> wrote:
>In article <31147008...@naggum.no> , Erik Naggum <cle...@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/>
Xah Lee
Sep 16, 1998, 3:00:00 AM9/16/98
to Xah
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, x...@best.com
http://www.best.com/~xah/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
"patterns" -- another moronic fad.
0 new messages