Because of what Raymond said. He said two things that I remember fairly clearly:
1) If you have to resort to OO to solve your problems, you probably have another unresolved problem at a higher level. This is from near the beginning of the book.
2) OO succeeds mainly by increasing the global complexity of the problem.
All I'm doing is answering your question. It is true I wasn't totally clear about this. It is very clear that you understand his detailed logic better than I do. Reading the rest of your post now.
Ok, I see. Raymond wrote this in 2003, at the peak height of "Java OO madness" where deep inheritance and over-engineered, totally inefficient systems were common. In The Art of Unix Programming, Raymond clarifies that he isn't against "objects" as a conceptual tool but against the "gospel of OO" that dominated the 1990s. His main argument is not that OO is inherently "evil", but that OO designs often become "spaghetti-like tangles" of inheritance hierarchies that hide logic behind "thick layers of glue". He represents the "Unix Philosophy", which is a specific culture, and he was writing to defend this culture against the rising tide of Java and C++, which he saw as a threat to the simplicity and "text-based" interoperability of Unix. Interestingly, Wirth’s Oberon and OO approach actually aligns well with much of Raymond's philosophy. Raymond would certainly agree that OO is just one of many tools in the toolbox of an engineer, and our job is it to chose the right tools for the job.
Comments
"Why?"
Because of what Raymond said. He said two things that I remember fairly clearly:
1) If you have to resort to OO to solve your problems, you probably have another unresolved problem at a higher level. This is from near the beginning of the book.
2) OO succeeds mainly by increasing the global complexity of the problem.
All I'm doing is answering your question. It is true I wasn't totally clear about this. It is very clear that you understand his detailed logic better than I do. Reading the rest of your post now.
Ok, I see. Raymond wrote this in 2003, at the peak height of "Java OO madness" where deep inheritance and over-engineered, totally inefficient systems were common. In The Art of Unix Programming, Raymond clarifies that he isn't against "objects" as a conceptual tool but against the "gospel of OO" that dominated the 1990s. His main argument is not that OO is inherently "evil", but that OO designs often become "spaghetti-like tangles" of inheritance hierarchies that hide logic behind "thick layers of glue". He represents the "Unix Philosophy", which is a specific culture, and he was writing to defend this culture against the rising tide of Java and C++, which he saw as a threat to the simplicity and "text-based" interoperability of Unix. Interestingly, Wirth’s Oberon and OO approach actually aligns well with much of Raymond's philosophy. Raymond would certainly agree that OO is just one of many tools in the toolbox of an engineer, and our job is it to chose the right tools for the job.