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: Barkster on 14 Sep 2006 14:17 No it completely close the window. Patrick May wrote: > "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, espe
From: topmind on 14 Sep 2006 14:47 Patrick May wrote: > "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. It is what I encounter. > > > 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 am not sure what you mean. Additional tools that add only marginal improvements are often not worth it. Only add additional tools/layers if it adds *significant* improvement. It makes staffing more difficult for managers also. Perhaps as developers we don't care because staffing is not our concern, but affects the bottom line. > > 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. Or somebody who wants to pad their resume with buzzwords. > >> 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. I have not seen code where it has clearly *added* value, outside of systems software. > > >> > 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? http://www.geocities.com/tablizer/struc.htm > >> 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? Not really. It's proprietary. > > The most obvious case in which the centralized database > architecture cannot work is when a system must interact with an > external system. A vendor will send flat files and may even provide a > Web Service, but none will share a database. Well, if they make tools that only use communication protocol X, that is not the fault of the paradigm/technique itself. But web services and flat files are merely transfer mechanisms. One could transfer stuff to and from a database also using those. > > Another example comes from telecommunications. Even a small > network operator will have a wide variety of systems including > billing, rating, CRM, MRP/ERP, provisioning, network
From: Patrick May on 15 Sep 2006 05:30 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> 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. > > It is what I encounter. Just to be clear, are you stating that everyone who finds some benefits in OO techniques does not understand procedural and relational techniques? >> > 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 am not sure what you mean. Software development "paradigms" have fuzzy boundaries. Talking about mixing them implies that they are discrete, when in fact they are pre-mixed to some degree. One of the reasons I prefer C++ to Java (Heretic! Burn him!) in some cases is that it supports OO, procedural, and generic programming simultaneously. What causes confusion isn't mixing paradigms but inconsistent use of the available techniques. This can and does compromise maintainability and extensibility. The answer is project standards, not tool restrictions. > Additional tools that add only marginal improvements are often not > worth it. Only add additional tools/layers if it adds *significant* > improvement. In my experience and the experience of other developers I've worked with, the dependency management benefits of using OO techniques provide real value and are no more difficult to use than procedural techniques. In fact, OO languages express and support certain techniques directly that must be implemented by developers using procedural languages. What environments have you worked in where OO was demonstrated not to provide value? What languages were used? What techniques were tried? > It makes staffing more difficult for managers also. Perhaps as > developers we don't care because staffing is not our concern, but > affects the bottom line. I do a fair bit of interviewing and hiring. One of the first questions I ask is "What languages other than Java do you know well?" Another couple are "What are the disadvantages of your favorite language?" and "What are the advantages of your least favorite language?" If someone interviewing for a senior developer or technical architect role isn't familiar with several different paradigms and a half-dozen languages from across the spectrum, they are unlikely to be the type of person I'm looking for. A team of developers who are enthusiastic about technology and capable of providing multiple perspectives on the solution to a problem are what will really affect the bottom line -- positively. >> 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. > > Or somebody who wants to pad their resume with buzzwords. That's uncharitable to the point of bitterness. Certainly there are some people who hop from project to project in order to pad their resume. I'm referring to people who actually understand and can apply those techniques. Eric S. Raymond put it very well: Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot. The same applies (to a lesser degree ;-) to learning any new development techniques. Even if you don't use them, knowing them will change the way you think about solving problems. >> >> 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. > > I have not seen code where it has clearly *added* value, outside of > systems software. Where, specifically, have you used OO techniques and found no additional value? What techniques were you using? What languages? What were your metrics for measuring value? >> >> 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? > > http://www.geocities.com/tablizer/struc.htm Is that an example from an actual project or simply one you contrived for your website? If it is from an actual project, what was the OO design that was proposed instead? If it isn't from an actual project, under what circumstances have you used OO techniques and found that they required a greater amount of effort to meet the same functional and non-functional requirements that could be more easily delivered via procedural and relational 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. >> > >> > 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.
From: topmind on 15 Sep 2006 16:35 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Patrick May wrote: > >> 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. > > > > It is what I encounter. > > Just to be clear, are you stating that everyone who finds some > benefits in OO techniques does not understand procedural and > relational techniques? No. I am only stating my experience. Anecdotes are all any of us have so far. > > >> > 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 am not sure what you mean. > > Software development "paradigms" have fuzzy boundaries. Talking > about mixing them implies that they are discrete, when in fact they > are pre-mixed to some degree. One of the reasons I prefer C++ to Java > (Heretic! Burn him!) in some cases is that it supports OO, > procedural, and generic programming simultaneously. > > What causes confusion isn't mixing paradigms but inconsistent use > of the available techniques. This can and does compromise > maintainability and extensibility. The answer is project standards, > not tool restrictions. Yet more techniques/paradigms is not going to help the consistency situation. It produces more different ways to solve the same problem. > > > Additional tools that add only marginal improvements are often not > > worth it. Only add additional tools/layers if it adds *significant* > > improvement. > > In my experience and the experience of other developers I've > worked with, the dependency management benefits of using OO techniques > provide real value and are no more difficult to use than procedural > techniques. In fact, OO languages express and support certain > techniques directly that must be implemented by developers using > procedural languages. A practical business example? > > What environments have you worked in where OO was demonstrated > not to provide value? What languages were used? What techniques were > tried? I would have to give too much background of the domain first. I'm not even sure I remember enough of it. I'll think about it to see if I can find a compact way to describe such. But the problem is that they didn't add any known improvement. It's a class, but so what. What is it supposed to help? Future changes? I don't think so. I could anticipate fairly likely realistic changes that would have kicked the class in the gonads. They just stood there being classes. On the flip side, can you offer an example class/object that was clearly better than the procedural/relational alternative and is not a language-specific fault? > > > It makes staffing more difficult for managers also. Perhaps as > > developers we don't care because staffing is not our concern, but > > affects the bottom line. > > I do a fair bit of interviewing and hiring. One of the first > questions I ask is "What languages other than Java do you know well?" > Another couple are "What are the disadvantages of your favorite > language?" and "What are the advantages of your least favorite > language?" If someone interviewing for a senior developer or > technical architect role isn't familiar with several different > paradigms and a half-dozen languages from across the spectrum, they > are unlikely to be the type of person I'm looking for. A team of > developers who are enthusiastic about technology and capable of > providing multiple perspectives on the solution to a problem are what > will really affect the bottom line -- positively. Providing multiple perspectives is good, but even better is describing *why* it is better. Making a class instead of a procedural module is offering multiple perspectives, but of limited use of one cannot show clearly why it is better. (I don't claim my techniques are always objectively better, just not objectively worse. A lot of it is fitting a person's pscychology.) > > >> 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. > > > > Or somebody who wants to pad their resume with buzzwords. > > That's uncharitable to the point of bitterness. Certainly there > are some people who hop from project to project in order to pad their > resume. I'm referring to people who actually understand and can apply > those techniques. Eric S. Raymond put it very well: > > Lisp is worth learning for the profound enlightenment experience > you will have when you finally get it; that experience will make > you a better programmer for the rest of your days, even if you > never actually use Lisp itself a lot. Agreed, but some "experiment on the job" excessively. I did not accuse you or all OO'ers of that, but only saying it happens fairly often and that one has to be careful. One should expand their mind outside of production projects. Develop a demo first, for example, and get feedback on it. Don't try a transharmonic multidimensional inverted visitor pattern for the first time on something due in 3 weeks. > > The same applies (to a lesser degree ;-) to learning any new > development techniques. Even if you don't use them, knowing them will > change the way you think about solving problems. > > >> >> 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
From: Patrick May on 16 Sep 2006 06:08
"topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> "topmind" <topmind(a)technologist.com> writes: >> >> 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. >> > >> > It is what I encounter. >> >> Just to be clear, are you stating that everyone who finds some >> benefits in OO techniques does not understand procedural and >> relational techniques? > > No. I am only stating my experience. So you have never encountered a single developer who understands procedural and relational programming but still finds value in OO techniques? Not one? > Anecdotes are all any of us have so far. In this forum, in the absence of shared experience, we are indeed limited to descriptions of our experience and occasional references to often limited documentation of projects. That's why I'm asking questions of you -- your statements regarding OO are strongly at variance with my experience and that of developers I have worked with. >> What environments have you worked in where OO was demonstrated >> not to provide value? What languages were used? What techniques >> were tried? > > I would have to give too much background of the domain first. I'm > not even sure I remember enough of it. I'll think about it to see > if I can find a compact way to describe such. Start simple. How long ago was it? What was the general domain? What languages were used? What specific problems did you encounter? From your description, it sounds like you've only used OO on one project. Is this the only OO project you've ever worked on? If not, in what other domains have you applied OO technology? What specific problems did you encounter there? > But the problem is that they didn't add any known improvement. It's > a class, but so what. What is it supposed to help? Future changes? I > don't think so. I could anticipate fairly likely realistic changes > that would have kicked the class in the gonads. > > They just stood there being classes. Again, this suggests that you've only been exposed to OO techniques on one project. Is that the case? It also suggests that the design wasn't particularly behavior driven. What design methodology was used? >> Where, specifically, have you used OO techniques and found no >> additional value? What techniques were you using? What languages? >> What were your metrics for measuring value? > > Some of this was already discussed above. As far as what metric, > this is another contentious area. Nobody even agrees on what metric > OO does better on. Well, you said that OO techniques didn't add value. What metric were you using in that statement? >> > http://www.geocities.com/tablizer/struc.htm >> >> Is that an example from an actual project or simply one you >> contrived for your website? If it is from an actual project, what >> was the OO design that was proposed instead? If it isn't from an >> actual project, under what circumstances have you used OO >> techniques and found that they required a greater amount of effort >> to meet the same functional and non-functional requirements that >> could be more easily delivered via procedural and relational >> techniques? > > It is based on textbook OO examples. Textbook examples are of necessity limited and aimed at demonstrating one or a few particular points. Your statements indicate that you have seen the use of OO techniques fail to deliver value in a production development. Under what circumstances have you used OO techniques and found that they required a greater amount of effort to meet the same functional and non-functional requirements that could be more easily delivered via procedural and relational techniques? >> I'm saying that big iron is expensive, so alternatives to the >> centralized database architecture are necessary. > > Again, the cost bottleneck is usually software, not hardware. That also does not correspond to my experience, but it is a side issue so I'm not going to go further into it. I'd like to understand the basis for the differences in our viewpoints. Perhaps it will inform me about domains where OO techniques aren't particularly applicable. Perhaps it will suggest a way for me to explain my experience in terms of yours. At the very least, it should help to explain the sweeping statements you have made regarding OO. To aid in achieving this understanding, in addition to the questions above, what OO languages do you know well enough to use in production code? 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) |