5 ms·

Did OOP do this to us?

39 points by 10ren 18y ago

nihilocrat 18y ago
I just think it's the case where OOP does not implicitly guarantee the modularity and good architecture of applications, it simply provides a model where for many problem domains and with proper code discipline, it will. Nature always builds a better idiot. Most importantly, I think it might be some sort of "it's so expensive, it's GOT to work" effect. The complexity of OOP patterns can be pretty ridiculous, so perhaps people dilligently code away using them because they feel like there's nothing better, or they feel like the complexity has to be good for something.
- twoz 18y ago
  "it's so expensive, it's GOT to work" Exactly. “Simplicity is hard to build, easy to use, and hard to charge for. Complexity is easy to build, hard to use, and easy to charge for.”
  - apotheon 18y ago
    Where'd you get that second quote? It seems familiar.
    - twoz 18y ago
      As seen on Twitter by Chris Sacca: http://news.ycombinator.com/item?id=248322 http://news.ycombinator.com/item?id=248322
moe 18y ago
Reminds me of that old Yegge quote: Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly. -- Steve Yegge (2007, Codes Worst Enemy)
- lacker 18y ago
  link: http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
- russell 18y ago
  No. The long answer is that Java did it to us. Like jacquesm below, I have inherited a large Java enterprise project, 400,000 lines of Java, XML, JavaScript, HTML, and Flex. And no comments, JavaDoc, or design documentation. All of this seems to have been written by one person with smaller contributions by a couple of others. There seems to be lots of copy and paste and IDE generated code. The system was designed to be modular with plugin components. The first culprit is Java itself. The language is missing critical builtin data structures, ArrayList and Hashmap with corresponding literals. If they had been part of the language and not just libraries, Java might have taken a completely different direction. Throw in lack of overloadable operators, first class functions, and descent introspection and you get a language that in not very expressive. Lack of key fundamental data structures, leads to the OOP bandwagon. Interfaces and inheritance are good tools but they should be used in moderation. In my project there is the pattern of BaseInterface, BaseClass, MoreCompleteInterface, MoreCompleteClass, ModuleLevelInterface, and ModuleLevelClass all to implement a DAO with nothingg but getters and setters. In one case this adds up to more than 2000 lines of code that does nothing that could not have bee done with a hash. Just to make sure that the code is completely non-understandable most serious classes have something like this BaseInterface dataSource; along with a setter that is filled in by Spring at runtime. I cant even explore the class structure. Contrast this with Python, where it would be a handful of lines of code, maybe 100 or 200 times fewer. To get around the problems inherent in the language, Sun came up with beans and the Java community went charging off into complexity. And throw in XML configuration just to create an impedance barrier. Since this was all new territory, the result was an explosion of frameworks. So now I have a stack that includes JBoss, Spring, Hibernate, MySQL, 200k of JS libraries (some of which I never heard of before), Flex, Granite, and more open source Java libraries than I can shake a stick at. I suspect there are many cases of a library being added for a single feature. Java OK, JS not so OK because of download bloat. Maybe Java is not OK either because I have to deal with what broke when I upgrades to a new version. I particularly dislike the addition of Hibernate because it separates the programmer from the understanding of the database. In my case the database itself was generated from the the .hbm.xml files. The database was created from a Java-centric point of view as a network of classes. As a consequence Hibernate created hundreds of tables. One query to fill in a simple list in the browser created an SQL query with 10 joins. I'm surprised the db didn't roll over dead. At least I'm being paid well.
mechanical_fish 18y ago
I'm no expert on enterprise software, but this tallies with my casual observations. Note that Java didn't make enterprise software into a bloated, confusing architectural spaghetti. It just found its niche there. Remember that Java was originally intended for writing embedded software for set-top boxes; then it got repurposed for writing "write once, run anywhere" desktop applets. It is only because the language was a nigh-complete failure in those niches that it became primarily known as a language for server-side enterprise software, which has influenced its development ever since. So it might be that the enterprise development "pattern", memorably characterized by PG as "maintainable spaghetti", did this to (Java's) OOP, not the other way around. But I would suggest that it's a little of both: Java and the "enterprise pattern" are coevolved, like the chicken and its egg. At this point it's hard to sort out which came first. UPDATE: I should point out that the author says more or less the same thing: OOP didn't do this to us; we did it to ourselves. OOP just held our hats. His title is a rhetorical question, so the fact that I think it's subtly misleading is actually a sign that it's doing its job. ;)
- russell 18y ago
  You make a good point. Open (loosely used) enterprise software leads to committees and committees lead to kitchen sink specifications. CORBA, from a previous generation, had exactly that kind of bloat, W3C specifications likewise. The Java libraries show that in spectacular fashion. Maybe Sun thinks we need umpteen hash table implementations, but I think we would be better off with one well done. Frameworks done by committee are even worse. God save us from W3C and the Apache Foundation. Counterpoint: software from dictators: Python and Django.
  - eru 18y ago
    How does Haskell's collective approach to design / standardization stand here?
jacquesm 18y ago
I've just 'inherited' a fairly large java project, and while I doubt that java is the cause of this kind of problem it definitely makes it very easy to make these mistakes. Over enforcing the oop concept is a fantastic way of losing track of what is going on with your code, and it pretty much guarantees inefficiency, because 'abstraction' is just another way of saying "I don't want to know". What you don't know you can't analyze and what you can't analyze might very well be the cause of your problem. Good programmer (tm) can write excellent code in Java, because like any other tool it will respond to its handler. If you are just using classes to pile layer upon layer of unwanted abstractions on top of each other because you fail to grasp your problem properly then you have nobody to blame but yourself. Again, in some languages this kind of behaviour is actively encouraged and in some it is discouraged, I suspect that java is one of the former.
- ricky_clarkson 18y ago
  Java makes excellent code unreadable.
  - russell 18y ago
    ... and makes it possible to hide some pretty bad code/design among the abstractions.
    - jeffcoat 18y ago
      Well, yes: arguably, that very fact is one of the major wins you get from good abstractions.
timr 18y ago
For those who will vote this up without bothering to read past the title: the conclusion is that no, OOP is not responsible for bad programming. Bad programmers are responsible for bad programming. News at 11.
- joe_the_user 18y ago
  OOP has had several phases. The first phase conflated encapsulation into objects with generic reuse. It also advocated complex object diagrams, deep inheritance trees and a variety of over-elaborate approaches. The second phase was more closely related to patterns and agile methologies. Here, the illusion of OOP creating generic reuse was abandoned, the idea of "containment over inheritance" was broached, and the paradigm became closer to "the right tool for the job". I am actually amazed that methodologies were able to improve but I can't argue with what I've seen.
gjm11 18y ago
No. And that was this week's edition of Simple Answers To Simple Questions.
sdp 18y ago
"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 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/msg04045.html 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/ 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 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.
- apotheon 18y ago
  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.
dkarl 18y ago
Funny how people are so eager to attribute bad design to the design philosophy it attempted to follow. This guy at least acknowledges that as a trap, but he doesn't convince me that he isn't falling into it. Furthermore, if you read his other post that he links to, he pretty much admits that the things he blames on OOP are due to incompetent use of OOP: "The thing that wasn't equal was the tendency of humans to fill a new development technique's capacity for scalability as long as that technique is used. As OOP provided greater ability to write ever-larger programs, humans wrote ever-larger programs — even when they didn't need to do so (and probably shouldn't have done so)."
- apotheon 18y ago
  You did a very good job of paraphrasing much of what I said. I wonder why you phrased it as though you disagreed with me.
jerf 18y ago
I've read tons on the pros and cons of OO, done quite a lot of both OO and non-OO programming, and witnessed many other people try. My conclusion after all of this is that the debate on OO is almost entirely obscured by noise, because only 10-20% of developers are capable of using it even remotely correctly in practice. Many of the people yelling about how horrible it is are not in that 10-20%, either, and nor are many of the people singing (or, at least, "repeating") its praises. It may be sold as a technique that the masses can use, but this is demonstrably not true, if you examine the code the masses are producing.
- gruseom 18y ago
  Yeah, but as Tim Lister once said (about something else): if everybody gets it wrong, there's something wrong with it.
  - apotheon 18y ago
    . . . or at least with its choice of target audience.
  - jerf 18y ago
    I tend to agree. But it should be pointed out your observation extends to programming and architecture in general, and OO is just a special case of that. Most people are pretty bad at designing anything much past about ten thousand lines and almost everybody above that scope ends up producing "relatively maintainable spaghetti code", regardless of the language paradigm. I am also sympathetic to the idea that we shouldn't have architects as a separate, distinct position, but some way of recognizing your good designers and architects seems necessary, because you don't really want just anybody doing it.
    - dhimes 18y ago
      I tend to agree You shouldn't, because the original premise is wrong. You can ask most people very intuitive questions about physics (such as, if you are walking along and drop a book, where will the book land?) and they will get it wrong. They are wrong, not the physics. I agree strongly with your original premise: most don't understand how to use it properly. I recommend Allen Holub for learning.
david927 18y ago
No, ambition and sloth did this to us: Ambition in the scope of the systems we build, sloth in our willingness to give in to whatever gets the job done. As Alan Kay said, "The revolution hasn't happened yet." He knows that OOP isn't the final answer (although I think we're all thankful for its existence). He is one of a small group, made up of mainly self-funded geniuses and eccentrics, who are working in this space. Everyone else gave up. We had PARC in the 70's and really nothing else since; we're still coasting on what they accomplished there. Now that we know how important this is, why can't we fund a PARC again? Why can't we build a place where we throw it all out and start over? I know of a few places doing this now, including Viewpoint Research, but we need more.
msluyter 18y ago
I'm curious what the alternative is, if any?
- apotheon 18y ago
  Use OOP correctly. Don't turn OOP into the point of your programming style on any project. Don't use it at all when it's not appropriate. When you don't use OOP, make sure you're using the right thing for the problem domain at hand. When you use something programming paradigm other than OOP, make sure you use that correctly, too.
  - apotheon 18y ago
    I probably should have said "Avoid Java" in there somewhere, too.
- russell 18y ago
  As I alluded to in a rant just posted, I think deficiencies in Java as a language created a community of complexity where OOP was taken to the extreme, where interfaces, inheritance, and beans are used with abandon. Contrast this with Python and its community, where there is a less extreme approach to OOP, because the language itself is more expressive.
voidpointer 18y ago
In my opinion, a main reason for the situation described by the author is lack of architectural governance in large projects. The most senior programmer often is assigned the role of "the architect", even if he is more of a type that likes to obsess over details rather than the big picture. Such types are prone to dismiss the importance of conceptual integrity throughout a complex project which ultimately leads to the pile of unsustainable mess that many enterprise-class applications have become. Brooks laid out the importance of conceptual integrity pretty well in in the mythical man month. It is often not taken serious enough today.
azgolfer 18y ago
OOP is an excellent tool when it is used to support separation of concerns. I'm actually working on a system where they lumped all the functions together, didn't try to separate them by obvious domain entities. This is inconvenient, but it is not nearly as bad as a poorly designed OOP framework. The problem that I see with the frameworks is not enough people ask the question "what does it really buy me ?". For instance relational databases give a huge benefit in ACID transactions, a query language that gives correct results, you can dynamically update tables without breaking things, dynamically join tables to give new kinds of results, etc.. So paying the price to use SQL to acess your data is not bad, because you get so much back. But what exaclty are you getting back from using a framework like Hibernate in between you and the database ? And where is the proof that ORM is even a good idea ? There seems to be an idea - if it is OO it is good, and if a lot of people are using it it must be good. I think these two assumptions are the real problem.

39 points by 10ren 18y ago

I just think it's the case where OOP does not implicitly guarantee the modularity and good architecture of applications, it simply provides a model where for many problem domains and with proper code discipline, it will. Nature always builds a better idiot. Most importantly, I think it might be some sort of "it's so expensive, it's GOT to work" effect. The complexity of OOP patterns can be pretty ridiculous, so perhaps people dilligently code away using them because they feel like there's nothing better, or they feel like the complexity has to be good for something.

twoz 18y ago
"it's so expensive, it's GOT to work" Exactly. “Simplicity is hard to build, easy to use, and hard to charge for. Complexity is easy to build, hard to use, and easy to charge for.”
- apotheon 18y ago
  Where'd you get that second quote? It seems familiar.
  - twoz 18y ago
    As seen on Twitter by Chris Sacca: http://news.ycombinator.com/item?id=248322 http://news.ycombinator.com/item?id=248322

moe 18y ago

Reminds me of that old Yegge quote: Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly. -- Steve Yegge (2007, Codes Worst Enemy)

lacker 18y ago
link: http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
russell 18y ago
No. The long answer is that Java did it to us. Like jacquesm below, I have inherited a large Java enterprise project, 400,000 lines of Java, XML, JavaScript, HTML, and Flex. And no comments, JavaDoc, or design documentation. All of this seems to have been written by one person with smaller contributions by a couple of others. There seems to be lots of copy and paste and IDE generated code. The system was designed to be modular with plugin components. The first culprit is Java itself. The language is missing critical builtin data structures, ArrayList and Hashmap with corresponding literals. If they had been part of the language and not just libraries, Java might have taken a completely different direction. Throw in lack of overloadable operators, first class functions, and descent introspection and you get a language that in not very expressive. Lack of key fundamental data structures, leads to the OOP bandwagon. Interfaces and inheritance are good tools but they should be used in moderation. In my project there is the pattern of BaseInterface, BaseClass, MoreCompleteInterface, MoreCompleteClass, ModuleLevelInterface, and ModuleLevelClass all to implement a DAO with nothingg but getters and setters. In one case this adds up to more than 2000 lines of code that does nothing that could not have bee done with a hash. Just to make sure that the code is completely non-understandable most serious classes have something like this BaseInterface dataSource; along with a setter that is filled in by Spring at runtime. I cant even explore the class structure. Contrast this with Python, where it would be a handful of lines of code, maybe 100 or 200 times fewer. To get around the problems inherent in the language, Sun came up with beans and the Java community went charging off into complexity. And throw in XML configuration just to create an impedance barrier. Since this was all new territory, the result was an explosion of frameworks. So now I have a stack that includes JBoss, Spring, Hibernate, MySQL, 200k of JS libraries (some of which I never heard of before), Flex, Granite, and more open source Java libraries than I can shake a stick at. I suspect there are many cases of a library being added for a single feature. Java OK, JS not so OK because of download bloat. Maybe Java is not OK either because I have to deal with what broke when I upgrades to a new version. I particularly dislike the addition of Hibernate because it separates the programmer from the understanding of the database. In my case the database itself was generated from the the .hbm.xml files. The database was created from a Java-centric point of view as a network of classes. As a consequence Hibernate created hundreds of tables. One query to fill in a simple list in the browser created an SQL query with 10 joins. I'm surprised the db didn't roll over dead. At least I'm being paid well.

mechanical_fish 18y ago

I'm no expert on enterprise software, but this tallies with my casual observations. Note that Java didn't make enterprise software into a bloated, confusing architectural spaghetti. It just found its niche there. Remember that Java was originally intended for writing embedded software for set-top boxes; then it got repurposed for writing "write once, run anywhere" desktop applets. It is only because the language was a nigh-complete failure in those niches that it became primarily known as a language for server-side enterprise software, which has influenced its development ever since. So it might be that the enterprise development "pattern", memorably characterized by PG as "maintainable spaghetti", did this to (Java's) OOP, not the other way around. But I would suggest that it's a little of both: Java and the "enterprise pattern" are coevolved, like the chicken and its egg. At this point it's hard to sort out which came first. UPDATE: I should point out that the author says more or less the same thing: OOP didn't do this to us; we did it to ourselves. OOP just held our hats. His title is a rhetorical question, so the fact that I think it's subtly misleading is actually a sign that it's doing its job. ;)

russell 18y ago
You make a good point. Open (loosely used) enterprise software leads to committees and committees lead to kitchen sink specifications. CORBA, from a previous generation, had exactly that kind of bloat, W3C specifications likewise. The Java libraries show that in spectacular fashion. Maybe Sun thinks we need umpteen hash table implementations, but I think we would be better off with one well done. Frameworks done by committee are even worse. God save us from W3C and the Apache Foundation. Counterpoint: software from dictators: Python and Django.
- eru 18y ago
  How does Haskell's collective approach to design / standardization stand here?

jacquesm 18y ago

I've just 'inherited' a fairly large java project, and while I doubt that java is the cause of this kind of problem it definitely makes it very easy to make these mistakes. Over enforcing the oop concept is a fantastic way of losing track of what is going on with your code, and it pretty much guarantees inefficiency, because 'abstraction' is just another way of saying "I don't want to know". What you don't know you can't analyze and what you can't analyze might very well be the cause of your problem. Good programmer (tm) can write excellent code in Java, because like any other tool it will respond to its handler. If you are just using classes to pile layer upon layer of unwanted abstractions on top of each other because you fail to grasp your problem properly then you have nobody to blame but yourself. Again, in some languages this kind of behaviour is actively encouraged and in some it is discouraged, I suspect that java is one of the former.

ricky_clarkson 18y ago
Java makes excellent code unreadable.
- russell 18y ago
  ... and makes it possible to hide some pretty bad code/design among the abstractions.
  - jeffcoat 18y ago
    Well, yes: arguably, that very fact is one of the major wins you get from good abstractions.

timr 18y ago

For those who will vote this up without bothering to read past the title: the conclusion is that no, OOP is not responsible for bad programming. Bad programmers are responsible for bad programming. News at 11.

joe_the_user 18y ago
OOP has had several phases. The first phase conflated encapsulation into objects with generic reuse. It also advocated complex object diagrams, deep inheritance trees and a variety of over-elaborate approaches. The second phase was more closely related to patterns and agile methologies. Here, the illusion of OOP creating generic reuse was abandoned, the idea of "containment over inheritance" was broached, and the paradigm became closer to "the right tool for the job". I am actually amazed that methodologies were able to improve but I can't argue with what I've seen.

gjm11 18y ago

No. And that was this week's edition of Simple Answers To Simple Questions.

sdp 18y ago

"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 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/msg04045.html 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/ 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 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.

apotheon 18y ago
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.

dkarl 18y ago

Funny how people are so eager to attribute bad design to the design philosophy it attempted to follow. This guy at least acknowledges that as a trap, but he doesn't convince me that he isn't falling into it. Furthermore, if you read his other post that he links to, he pretty much admits that the things he blames on OOP are due to incompetent use of OOP: "The thing that wasn't equal was the tendency of humans to fill a new development technique's capacity for scalability as long as that technique is used. As OOP provided greater ability to write ever-larger programs, humans wrote ever-larger programs — even when they didn't need to do so (and probably shouldn't have done so)."

apotheon 18y ago
You did a very good job of paraphrasing much of what I said. I wonder why you phrased it as though you disagreed with me.

jerf 18y ago

I've read tons on the pros and cons of OO, done quite a lot of both OO and non-OO programming, and witnessed many other people try. My conclusion after all of this is that the debate on OO is almost entirely obscured by noise, because only 10-20% of developers are capable of using it even remotely correctly in practice. Many of the people yelling about how horrible it is are not in that 10-20%, either, and nor are many of the people singing (or, at least, "repeating") its praises. It may be sold as a technique that the masses can use, but this is demonstrably not true, if you examine the code the masses are producing.

gruseom 18y ago
Yeah, but as Tim Lister once said (about something else): if everybody gets it wrong, there's something wrong with it.
- apotheon 18y ago
  . . . or at least with its choice of target audience.
- jerf 18y ago
  I tend to agree. But it should be pointed out your observation extends to programming and architecture in general, and OO is just a special case of that. Most people are pretty bad at designing anything much past about ten thousand lines and almost everybody above that scope ends up producing "relatively maintainable spaghetti code", regardless of the language paradigm. I am also sympathetic to the idea that we shouldn't have architects as a separate, distinct position, but some way of recognizing your good designers and architects seems necessary, because you don't really want just anybody doing it.
  - dhimes 18y ago
    I tend to agree You shouldn't, because the original premise is wrong. You can ask most people very intuitive questions about physics (such as, if you are walking along and drop a book, where will the book land?) and they will get it wrong. They are wrong, not the physics. I agree strongly with your original premise: most don't understand how to use it properly. I recommend Allen Holub for learning.

david927 18y ago

No, ambition and sloth did this to us: Ambition in the scope of the systems we build, sloth in our willingness to give in to whatever gets the job done. As Alan Kay said, "The revolution hasn't happened yet." He knows that OOP isn't the final answer (although I think we're all thankful for its existence). He is one of a small group, made up of mainly self-funded geniuses and eccentrics, who are working in this space. Everyone else gave up. We had PARC in the 70's and really nothing else since; we're still coasting on what they accomplished there. Now that we know how important this is, why can't we fund a PARC again? Why can't we build a place where we throw it all out and start over? I know of a few places doing this now, including Viewpoint Research, but we need more.

msluyter 18y ago

I'm curious what the alternative is, if any?

apotheon 18y ago
Use OOP correctly. Don't turn OOP into the point of your programming style on any project. Don't use it at all when it's not appropriate. When you don't use OOP, make sure you're using the right thing for the problem domain at hand. When you use something programming paradigm other than OOP, make sure you use that correctly, too.
- apotheon 18y ago
  I probably should have said "Avoid Java" in there somewhere, too.
russell 18y ago
As I alluded to in a rant just posted, I think deficiencies in Java as a language created a community of complexity where OOP was taken to the extreme, where interfaces, inheritance, and beans are used with abandon. Contrast this with Python and its community, where there is a less extreme approach to OOP, because the language itself is more expressive.

voidpointer 18y ago

In my opinion, a main reason for the situation described by the author is lack of architectural governance in large projects. The most senior programmer often is assigned the role of "the architect", even if he is more of a type that likes to obsess over details rather than the big picture. Such types are prone to dismiss the importance of conceptual integrity throughout a complex project which ultimately leads to the pile of unsustainable mess that many enterprise-class applications have become. Brooks laid out the importance of conceptual integrity pretty well in in the mythical man month. It is often not taken serious enough today.

azgolfer 18y ago

OOP is an excellent tool when it is used to support separation of concerns. I'm actually working on a system where they lumped all the functions together, didn't try to separate them by obvious domain entities. This is inconvenient, but it is not nearly as bad as a poorly designed OOP framework. The problem that I see with the frameworks is not enough people ask the question "what does it really buy me ?". For instance relational databases give a huge benefit in ACID transactions, a query language that gives correct results, you can dynamically update tables without breaking things, dynamically join tables to give new kinds of results, etc.. So paying the price to use SQL to acess your data is not bad, because you get so much back. But what exaclty are you getting back from using a framework like Hibernate in between you and the database ? And where is the proof that ORM is even a good idea ? There seems to be an idea - if it is OO it is good, and if a lot of people are using it it must be good. I think these two assumptions are the real problem.