what's the future of Object Oriented Programming
in [OOP]
|
Prev: Deriving - .NET example
Next: Polymorphism Downsides (was: what's the future of Object Oriented Programming)
From: Patrick May on 12 Sep 2006 02:16 "topmind" <topmind(a)technologist.com> writes: > H. S. Lahman wrote: >> Reuse is nice but not a major consideration in using OO techniques. >> The real objective of OO development is to create maintainable >> applications in the face of volatile requirements over the product >> life cycle. >> >> To answer your title question, OO programming is still the only >> game in town for producing maintainable software. > > I beg to differ. There is no evidence for this, at least outside of > systems software. Actually, there is considerable evidence that some of the concepts typically grouped together under the term "object oriented" provide significant benefits in managing dependencies between software components, which results in more maintainable software. I don't know of anyone who has used OO in a large project and regretted having those tools available. "The only game in town" is overstating the case a bit, because similar techniques can be applied in most non-OO languages and functional languages, for example, offer still other approaches. Out of curiosity, what do you mean by "systems software?" Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: topmind on 12 Sep 2006 13:16 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > H. S. Lahman wrote: > >> Reuse is nice but not a major consideration in using OO techniques. > >> The real objective of OO development is to create maintainable > >> applications in the face of volatile requirements over the product > >> life cycle. > >> > >> To answer your title question, OO programming is still the only > >> game in town for producing maintainable software. > > > > I beg to differ. There is no evidence for this, at least outside of > > systems software. > > Actually, there is considerable evidence that some of the > concepts typically grouped together under the term "object oriented" > provide significant benefits in managing dependencies between software > components, which results in more maintainable software. The only examples I've seen are from people who didn't know how to use procedural and databases well. > I don't know > of anyone who has used OO in a large project and regretted having > those tools available. I've heard mumblings of things not going so smooth. Satisfaction surveys by Yourdon showed no improvement. Further, OOP tends to *create* large projects. Procedural/relational projects tend to break big problems into smaller applications that feed off of databases. The database is the Nile and small apps are villages on the shore. Thus, one mostly only has to know about the schemas and a few sanctioned library routines. > "The only game in town" is overstating the > case a bit, because similar techniques can be applied in most non-OO > languages and functional languages, for example, offer still other > approaches. > > Out of curiosity, what do you mean by "systems software?" Tool building, such as OS's, RDBMS engines, compilers, device drivers, network engines, etc. Polymorphism seems to have more use there. > > Sincerely, > > Patrick > -T-
From: Patrick May on 13 Sep 2006 02:51 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> "topmind" <topmind(a)technologist.com> writes: >> > H. S. Lahman wrote: >> >> Reuse is nice but not a major consideration in using OO >> >> techniques. The real objective of OO development is to create >> >> maintainable applications in the face of volatile requirements >> >> over the product life cycle. >> >> >> >> To answer your title question, OO programming is still the only >> >> game in town for producing maintainable software. >> > >> > I beg to differ. There is no evidence for this, at least outside of >> > systems software. >> >> Actually, there is considerable evidence that some of the >> concepts typically grouped together under the term "object >> oriented" provide significant benefits in managing dependencies >> between software components, which results in more maintainable >> software. > > The only examples I've seen are from people who didn't know how to > use procedural and databases well. You need to get out more. ;-) I started out after college working for a CASE tool company that ate its own dog food by using the tool to deliver projects. It was entirely based on E-R and dataflow modeling (Gane-Sarson, Yourdon-DeMarco, etc.). We delivered a lot of systems on time and within budget. Fast forward a few years and I encountered OO for the first time in the guise of Zortech C++. Some of the techniques were unlike what I knew, but many were logical extensions of good procedural practices. OO was more evolutionary than revolutionary and definitely a valuable addition to my virtual toolbox. Most of the experienced developers I know who have proven their ability to deliver quality software have similar backgrounds. They understand and use the procedural and relational approach very well, and they also have OO techniques to draw on. >> I don't know of anyone who has used OO in a large project and >> regretted having those tools available. > > I've heard mumblings of things not going so smooth. Satisfaction > surveys by Yourdon showed no improvement. Creating new things in the real world can be difficult. Complex projects never go completely smoothly. In my experience and that of other competent software developers I know, OO techniques provide mechanisms for managing dependencies and complexity that result in better quality software delivered more reliably. Where have you used OO techniques and found this not to be the case? > Further, OOP tends to *create* large projects. This is not my experience. Having more techniques available to manage dependencies and complexity helps to make systems as simple as possible. Restricting the available tools adds to the effort. What project have you worked on where the use of OO techniques resulted in a larger amount of effort for the same level of quality that could have been attained more simply without them? > Procedural/relational projects tend to break big problems into > smaller applications that feed off of databases. The database is the > Nile and small apps are villages on the shore. Thus, one mostly only > has to know about the schemas and a few sanctioned library routines. First, OO techniques permit just as much if not more functional decomposition as procedural. OO subsumes procedural techniques. Second, the "big central database" architecture is not universally applicable. Even when it is possible to architect a system that way, it does not always provide the best structure for the solution. >> "The only game in town" is overstating the case a bit, because >> similar techniques can be applied in most non-OO languages and >> functional languages, for example, offer still other approaches. >> >> Out of curiosity, what do you mean by "systems software?" > > Tool building, such as OS's, RDBMS engines, compilers, device > drivers, network engines, etc. Polymorphism seems to have more use > there. I have personally seen OO techniques used successfully in domains ranging from broadcast video to pharmaceuticals to finance to telecommunications. These are commonly considered "business applications." Where have you seen OO techniques fail in such systems? Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: topmind on 13 Sep 2006 15:46 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Patrick May wrote: > >> "topmind" <topmind(a)technologist.com> writes: > >> > H. S. Lahman wrote: > >> >> Reuse is nice but not a major consideration in using OO > >> >> techniques. The real objective of OO development is to create > >> >> maintainable applications in the face of volatile requirements > >> >> over the product life cycle. > >> >> > >> >> To answer your title question, OO programming is still the only > >> >> game in town for producing maintainable software. > >> > > >> > I beg to differ. There is no evidence for this, at least outside of > >> > systems software. > >> > >> Actually, there is considerable evidence that some of the > >> concepts typically grouped together under the term "object > >> oriented" provide significant benefits in managing dependencies > >> between software components, which results in more maintainable > >> software. > > > > The only examples I've seen are from people who didn't know how to > > use procedural and databases well. > > You need to get out more. ;-) > > I started out after college working for a CASE tool company that > ate its own dog food by using the tool to deliver projects. It was > entirely based on E-R and dataflow modeling (Gane-Sarson, > Yourdon-DeMarco, etc.). We delivered a lot of systems on time and > within budget. Fast forward a few years and I encountered OO for the > first time in the guise of Zortech C++. Some of the techniques were > unlike what I knew, but many were logical extensions of good > procedural practices. OO was more evolutionary than revolutionary and > definitely a valuable addition to my virtual toolbox. > > Most of the experienced developers I know who have proven their > ability to deliver quality software have similar backgrounds. They > understand and use the procedural and relational approach very well, > and they also have OO techniques to draw on. Nobody ever agrees on when to use which paradigm. Plus, mixing gajillion paradigms can create quite a mess and confusion and translation effort between them. > > >> I don't know of anyone who has used OO in a large project and > >> regretted having those tools available. > > > > I've heard mumblings of things not going so smooth. Satisfaction > > surveys by Yourdon showed no improvement. > > Creating new things in the real world can be difficult. Complex > projects never go completely smoothly. In my experience and that of > other competent software developers I know, OO techniques provide > mechanisms for managing dependencies and complexity that result in > better quality software delivered more reliably. I have yet to see coded examples of it being better in my domain. > > Where have you used OO techniques and found this not to be the > case? I cannot remember specific details, but putting OO in the code did not improve the app any way that I saw. > > > Further, OOP tends to *create* large projects. > > This is not my experience. Having more techniques available to > manage dependencies and complexity helps to make systems as simple as > possible. Restricting the available tools adds to the effort. To a point, but paradigm potpourri has its own downsides, as described above. > > What project have you worked on where the use of OO techniques > resulted in a larger amount of effort for the same level of quality > that could have been attained more simply without them? Polymorphism is too course a granulation of variation management. I find set theoery better and OOP does not natively support set theory. OO's other approach to variation management, aggregation and composition are the same kind of navigational messes that prompted Dr. Codd to rework navigational structures. OO results in a big sea of classes with no easy to way navigate them all. Graph-oriented query systems to sift and study the pointer sea (navigational) thus far stink. They sucked in the 60's and they still suck as classes/objects. The Document Object Model is another example of an OO mess. > > > Procedural/relational projects tend to break big problems into > > smaller applications that feed off of databases. The database is the > > Nile and small apps are villages on the shore. Thus, one mostly only > > has to know about the schemas and a few sanctioned library routines. > > First, OO techniques permit just as much if not more functional > decomposition as procedural. OO subsumes procedural techniques. They are both Turing Equivalent. > > Second, the "big central database" architecture is not > universally applicable. Even when it is possible to architect a > system that way, it does not always provide the best structure for the > solution. For 90%+ of all biz apps I've worked on, it was, especially if nimble/local database engines are provided to suppliment big-iron DB's. Ironically, chasing OO is one reason why vendors abandoned nimble/local DB engines in tools in the 90's, setting app development back a decade. > > >> "The only game in town" is overstating the case a bit, because > >> similar techniques can be applied in most non-OO languages and > >> functional languages, for example, offer still other approaches. > >> > >> Out of curiosity, what do you mean by "systems software?" > > > > Tool building, such as OS's, RDBMS engines, compilers, device > > drivers, network engines, etc. Polymorphism seems to have more use > > there. > > I have personally seen OO techniques used successfully in domains > ranging from broadcast video to pharmaceuticals to finance to > telecommunications. These are commonly considered "business > applications." Where have you seen OO techniques fail in such > systems? I don't think they outright fail. They are just harder to get right and are messier than alternatives. There are no consistent, tested, and documented rule for converting biz logic to OO, and the issue of categorization and classification of things/objects/nouns/variations tend to fight with RDBMS for that role. Classification of business nouns belongs in the database IMO, not app code, and if you do that, you take away what OO usually does. > > Sincerely, > > Patrick > -T-
From: Patrick May on 14 Sep 2006 03:21
"topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> "topmind" <topmind(a)technologist.com> writes: >> >> Actually, there is considerable evidence that some of the >> >> concepts typically grouped together under the term "object >> >> oriented" provide significant benefits in managing dependencies >> >> between software components, which results in more maintainable >> >> software. >> > >> > The only examples I've seen are from people who didn't know how >> > to use procedural and databases well. >> >> You need to get out more. ;-) >> >> I started out after college working for a CASE tool company >> that ate its own dog food by using the tool to deliver projects. >> It was entirely based on E-R and dataflow modeling (Gane-Sarson, >> Yourdon-DeMarco, etc.). We delivered a lot of systems on time and >> within budget. Fast forward a few years and I encountered OO for >> the first time in the guise of Zortech C++. Some of the techniques >> were unlike what I knew, but many were logical extensions of good >> procedural practices. OO was more evolutionary than revolutionary >> and definitely a valuable addition to my virtual toolbox. >> >> Most of the experienced developers I know who have proven >> their ability to deliver quality software have similar backgrounds. >> They understand and use the procedural and relational approach very >> well, and they also have OO techniques to draw on. > > Nobody ever agrees on when to use which paradigm. I was responding to your statement that people who find benefits in OO techniques don't understand procedural and relational techniques. That's not at all the case. > Plus, mixing gajillion paradigms can create quite a mess and > confusion and translation effort between them. The nice thing about software development is that it gives us so many ways to cause ourselves problems. Your objection is just as valid within a "single paradigm" as a "multi paradigm" environment. I used the scare quotes because the term "paradigm" is overused and emphasizes the differences between two somewhat arbitrary sets of techniques at the expense of the similarities. OO is a superset of procedural. It may be difficult to use an OO style interface from some procedural languages, but the reverse is not often the case. The solution to some problems is expressed better declaratively than procedurally, others better in an OO style than declaratively, still others better functionally than object orientedly (to coin an inelegant phrase). Simply knowing these approaches allows one to see more solutions. Having all of these techniques available is what distinguishes a master developer from an apprentice. >> >> I don't know of anyone who has used OO in a large project and >> >> regretted having those tools available. >> > >> > I've heard mumblings of things not going so smooth. Satisfaction >> > surveys by Yourdon showed no improvement. >> >> Creating new things in the real world can be difficult. >> Complex projects never go completely smoothly. In my experience >> and that of other competent software developers I know, OO >> techniques provide mechanisms for managing dependencies and >> complexity that result in better quality software delivered more >> reliably. > > I have yet to see coded examples of it being better in my domain. What industry do you specialize in? What kinds of projects? I can't imagine a situation where having fewer options would be preferable. >> Where have you used OO techniques and found this not to be the >> case? > > I cannot remember specific details, but putting OO in the code did > not improve the app any way that I saw. Your statements contradict my experience and that of many people I've worked with. I'd like to understand where OO techniques have failed to add value for other people and why that was the case. Any specifics you can provide would help. >> > Further, OOP tends to *create* large projects. >> >> This is not my experience. Having more techniques available >> to manage dependencies and complexity helps to make systems as >> simple as possible. Restricting the available tools adds to the >> effort. > > To a point, but paradigm potpourri has its own downsides, as > described above. Again, I haven't found this to be the case in general. I've been using service oriented architectures (SOAs) over the past few years. One of the advantages of SOA is that the implementation of each service can use the most appropriate technology. >> What project have you worked on where the use of OO techniques >> resulted in a larger amount of effort for the same level of quality >> that could have been attained more simply without them? > > Polymorphism is too course a granulation of variation management. But where, specifically, have you used OO techniques and found that it resulted in a greater amount of effort for the same functional and non-functional capabilities that could have been more easily delivered using only procedural and relational techniques? >> > Procedural/relational projects tend to break big problems into >> > smaller applications that feed off of databases. The database is >> > the Nile and small apps are villages on the shore. Thus, one >> > mostly only has to know about the schemas and a few sanctioned >> > library routines. >> >> First, OO techniques permit just as much if not more >> functional decomposition as procedural. OO subsumes procedural >> techniques. > > They are both Turing Equivalent. So is INTERCAL, at least in theory. Turing equivalence is meaningless in practice -- what's important is expressiveness. Having more tools in the virtual toolbox allows for greater expressiveness. >> Second, the "big central database" architecture is not >> universally applicable. Even when it is possible to architect a >> system that way, it does not always provide the best structure for >> the solution. > > For 90%+ of all biz apps I've worked on, it was, especially if > nimble/local database engines are provided to suppliment big-iron > DB's. This doesn't correspond with my experience, nor with that of many people I've worked with. What details can you provide about your last three or four projects without violating any NDAs? The most obvio |