"OOP didn't do this to us; we did it to ourselves. OOP just held our hats."
I support the article's claim that programmers are responsible for spaghetti code, but I disagree that OOP in general is responsible for facilitating this behavior. Compare Java's OO to smalltalk's OO.
On the other hand you have an open source ecosystem built on top of a VM, where all code is available for modification and extension by the user. [http://www.squeak.org/About/]
Java programs are notorious for being resource hogs and unstable, and smalltalk programs are notorious for the opposite.
This dichotomy suggests OOP is not the evil villain it's made out to be. Rather, I would suggest that the average quality of code produced in a particular language is proportional to how easy it is to read other people's code in that language.
Java makes it very easy to hide your code. Often while working on a large Java project at school, each of my team mates and I divide the project into classes and we are each responsible for a particular set of classes. We don't ever need to look at one another's code to complete the assignment, and thus bugs can creep in.
On the other hand, I work on a mid-size PHP code base which is my responsibility alone. Thankfully, one of my co-workers is an excellent PHP coder. Whenever I make revisions to the code, I ask him to review my code. The mere knowledge that someone else is going to read the code I write is enough impetus for me to write better code in the hope that someday he won't find something I'll need to revise.
This is supported by the generally higher quality of code in very shared languages like C, Smalltalk and Python, than in seldom shared languages like Java, C++ and Cobol.
Clearly, C has a high potential for code hiding, but a community of code sharing (Unix) was built around the language to address this issue.
As the author you quoted and reviewed, I'll say this:
1. Thank you for the input.
2. I think you're imagining a greater amount of blame being heaped on OOP than I actually intended. That may be the fault of unclear presentation on my part, though.
3. The second half of your comment is most excellent, and quite worth the read. Thanks for making these points so well.
After reading your OOP and the Death of Modularity [http://sob.apotheon.org/?p=935], I see your point more clearly. (I'm not very perspicacious ;-)
Your point is that OOP "creates a means of loosely coupling code in a given complex system," which is considerably more scalable than tightly coupled code, which in turn leads to ever larger programs.
My comparison of Java and Smalltalk was meant to show that there exists versions of OOP which completely decouple code. In a Smalltalk VM (or at least in Squeak), each object you create is immediately available to you as though it were a command line utility.
This is very much in the spirit of the unix philosophy which you cite in both entries:
"...certain older development philosophies (like "the Unix philosophy") that provided significantly better modularity and significantly reduced complexity." [http://sob.apotheon.org/?p=935]
"Unix is the tradition of decoupled code, whence the very notion of a user environment composed entirely of programs that "do one thing well" comes to mind." [http://sob.apotheon.org/?p=245]
Thanks for coming back after reading Death of Modularity to examine the matter further. I've certainly heard such good things about (properly used) Smalltalk, but while many people compare Ruby to Smalltalk (and Ruby is the language I've used most, lately) I haven't really experienced these Smalltalk systems themselves, so I tend to refrain from saying too much bout Smalltalk (lest I make an ass of myself).
I support the article's claim that programmers are responsible for spaghetti code, but I disagree that OOP in general is responsible for facilitating this behavior. Compare Java's OO to smalltalk's OO.
On the one hand, you have "a halfway point between C++ and Lisp" which inherits a bytecode on virtual machine implementation from lisp and most everything else from C++. [http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...]
On the other hand you have an open source ecosystem built on top of a VM, where all code is available for modification and extension by the user. [http://www.squeak.org/About/]
Java programs are notorious for being resource hogs and unstable, and smalltalk programs are notorious for the opposite.
This dichotomy suggests OOP is not the evil villain it's made out to be. Rather, I would suggest that the average quality of code produced in a particular language is proportional to how easy it is to read other people's code in that language.
Java makes it very easy to hide your code. Often while working on a large Java project at school, each of my team mates and I divide the project into classes and we are each responsible for a particular set of classes. We don't ever need to look at one another's code to complete the assignment, and thus bugs can creep in.
On the other hand, I work on a mid-size PHP code base which is my responsibility alone. Thankfully, one of my co-workers is an excellent PHP coder. Whenever I make revisions to the code, I ask him to review my code. The mere knowledge that someone else is going to read the code I write is enough impetus for me to write better code in the hope that someday he won't find something I'll need to revise.
My experience is not an isolated case, as can be seen in this article by Jeff Atwood who quotes Code Complete: [http://www.codinghorror.com/blog/archives/000495.html].
This is supported by the generally higher quality of code in very shared languages like C, Smalltalk and Python, than in seldom shared languages like Java, C++ and Cobol.
Clearly, C has a high potential for code hiding, but a community of code sharing (Unix) was built around the language to address this issue.