Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: Patrick May on 5 Feb 2007 18:13 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> >> If you can't prove it, retract it and stop making such claims. >> > >> > I am not implying that something is better. >> >> Yes, you are. You clearly stated in the post that started >> this subthread that "If you embraced the DB instead of spend all >> your code wrapping it, the app would be noticably simpler." That >> is a clear, positive claim that you have been trying desperately to >> squirm out of supporting. > > I supported it in the message you are replying to. No, you didn't. If you think you did, provide the exact quote. >> Even if you don't use the additional techniques, knowing them will >> enable you to view a problem from more perspectives and come up >> with a better solution. > > Perhaps, but irrelavent. We are talking about the end product. It is completely relevant when the purpose is to create the best possible end product. Ignoring and refusing to learn new techniques is not the path to quality. >> > However, it logically follows that if you are using a relational >> > database, then designing the application close to it rather than >> > trying to wrap it away in OO classes and conventions will >> > simplify the design because one is not translating from one >> > paradigm to another. >> >> If you're thinking of a CRUD system, then you're correct. For >> any system with more complex behavior, you're going to need to >> provide some support for that assertion. (I'm not holding my >> breath.) > > Show me typical complex behavior in a biz app that relational chokes > on. Once again you've got it backward. You are the one making the claim above. It is up to you to support it or retract it. >> I don't find your question coherent as stated. I frequently >> use languages like Common Lisp and C++ that are considered >> multiparadigm. Multiparadigm languages offer a great deal more >> flexibility than more constrained languages like Java. Solutions >> that are infeasible in a less flexible language become the most >> elegant alternative when the appropriate constructs are available. > > Perhaps, but that is not realistic for staffing purposes, per above. I'm not sure what you're referring to "per above", but I haven't had a huge amount of difficulty hiring developers experienced in more than one set of techniques. > Most programmers don't have time to master 5 or so paradigms. You seem to be hung up on the word "paradigm". Object oriented, procedural, functional, relational, and other "paradigms" are just names given to sets of techniques and idioms. The boundaries of the sets are not clearly defined and there is extensive overlap. Let go of the words and focus on becoming a better developer by learning new techniques, regardless of what arbitrary set they happen to be part of today. If the best solution to a customer's problem requires that I encapsulate SQL in a function that I invoke within a closure passed to a polymorphic (multi)method of a class, that's what I'll do. Thus far the Pure Paradigm Furies have failed to strike me down. >> The closest I can come to an answer to your question is the >> observation that a having variety of options is better than lacking >> options. > > Not necessarily, per above. You are arguing that ignorance is superior to knowledge. > In my opinion it is best to pick a few complimentary tools and > master them than a mishmash potpurri of tools with similar > uses. There are a few people who can and do master most paradigms, > but that is the exception. Not in my experience. Good developers, such as the ones I try to work with frequently, have no difficulty using combinations of techniques and idioms. Interestingly, none of them find the concept of a "paradigm" particularly useful. Let it go. > [snipped links to past he-said-she-said fights. Nobody cares about > our old squabbles and it proved fruitless the last time we did it > because you think weird and interpret my writing in an odd way that > takes too long to correct, wasting time on nothing.] In other words, I proved that point so thoroughly that even you can't see how to squirm around it. Transcend paradigms, 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: Patrick May on 5 Feb 2007 18:21 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> >> If you can't prove it, retract it and stop making such claims. >> > >> > I am not implying that something is better. >> >> Yes, you are. You clearly stated in the post that started >> this subthread that "If you embraced the DB instead of spend all >> your code wrapping it, the app would be noticably simpler." That >> is a clear, positive claim that you have been trying desperately to >> squirm out of supporting. > > I supported it in the message you are replying to. No, you didn't. If you think you did, provide the exact quote. >> Even if you don't use the additional techniques, knowing them will >> enable you to view a problem from more perspectives and come up >> with a better solution. > > Perhaps, but irrelavent. We are talking about the end product. It is completely relevant when the purpose is to create the best possible end product. Ignoring and refusing to learn new techniques is not the path to quality. >> > However, it logically follows that if you are using a relational >> > database, then designing the application close to it rather than >> > trying to wrap it away in OO classes and conventions will >> > simplify the design because one is not translating from one >> > paradigm to another. >> >> If you're thinking of a CRUD system, then you're correct. For >> any system with more complex behavior, you're going to need to >> provide some support for that assertion. (I'm not holding my >> breath.) > > Show me typical complex behavior in a biz app that relational chokes > on. Once again you've got it backward. You are the one making the claim above. It is up to you to support it or retract it. >> I don't find your question coherent as stated. I frequently >> use languages like Common Lisp and C++ that are considered >> multiparadigm. Multiparadigm languages offer a great deal more >> flexibility than more constrained languages like Java. Solutions >> that are infeasible in a less flexible language become the most >> elegant alternative when the appropriate constructs are available. > > Perhaps, but that is not realistic for staffing purposes, per above. I'm not sure what you're referring to "per above", but I haven't had a huge amount of difficulty hiring developers experienced in a range of techniques. > Most programmers don't have time to master 5 or so paradigms. You seem to be hung up on the word "paradigm". Object oriented, procedural, functional, relational, and other "paradigms" are just names given to sets of techniques and idioms. The boundaries of the sets are not clearly defined and there is extensive overlap. Let go of the words and focus on becoming a better developer by learning new techniques, regardless of what arbitrary set they happen to be part of today. If the best solution to a customer's problem requires that I encapsulate SQL in a function that I invoke within a closure passed to a polymorphic (multi)method of a class for later evaluation by a rules engine, that's what I'll do. Thus far the Pure Paradigm Furies have failed to strike me down. >> The closest I can come to an answer to your question is the >> observation that a having variety of options is better than lacking >> options. > > Not necessarily, per above. You are arguing that ignorance is superior to knowledge. > In my opinion it is best to pick a few complimentary tools and > master them than a mishmash potpurri of tools with similar > uses. There are a few people who can and do master most paradigms, > but that is the exception. Not in my experience. Good developers, such as the ones I try to work with frequently, have no difficulty using combinations of techniques and idioms. Interestingly, none of them find the concept of a "paradigm" particularly useful. Let it go. > [snipped links to past he-said-she-said fights. Nobody cares about > our old squabbles and it proved fruitless the last time we did it > because you think weird and interpret my writing in an odd way that > takes too long to correct, wasting time on nothing.] In other words, I proved that point so thoroughly that even you can't see how to squirm around it. Transcend paradigms, 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: Daniel Parker on 6 Feb 2007 22:14 On Feb 5, 7:21 pm, "topmind" <topm...(a)technologist.com> wrote: > Martin hyped OO ... > Just out of curiousity, can you point out where RCM has "hyped OO"? I must have missed it, in the fifteen years or so I've been following his writings. (Now if you'd said "hyped XP", you'd have been on stronger ground :-)) Best regards, Daniel
From: topmind on 7 Feb 2007 01:23 On Feb 6, 7:14 pm, "Daniel Parker" <danielapar...(a)gmail.com> wrote: > On Feb 5, 7:21 pm, "topmind" <topm...(a)technologist.com> wrote: > > > Martin hyped OO ... > > Just out of curiousity, can you point out where RCM has "hyped OO"? I > must have missed it, in the fifteen years or so I've been following > his writings. (Now if you'd said "hyped XP", you'd have been on > stronger ground :-)) > > Best regards, > Daniel I cannot give a specific quote at the moment, but it is typical OO book argument-by-implication. For example, in chapter 7 he gives a typical device-driver-like example of a "copy" program. He then shows how bad case/if statements are for adding new devices and how polymorphism saves the day. It does not state that this may or may not be relavent outside of device drivers. There is no clear disclaimer anywhere I could find. The *implication* is that if poly is good here, it is good *everywhere*. "Argument by narrow example" you could call this phenom. I wonder where OO would be without animal, shape, and device-driver examples? If a judge forbid them, OO would probably be up pOOp creek. -T- oop.ismad.com
From: Mark Nicholls on 7 Feb 2007 05:46
On 7 Feb, 06:23, "topmind" <topm...(a)technologist.com> wrote: > On Feb 6, 7:14 pm, "Daniel Parker" <danielapar...(a)gmail.com> wrote: > > > On Feb 5, 7:21 pm, "topmind" <topm...(a)technologist.com> wrote: > > > > Martin hyped OO ... > > > Just out of curiousity, can you point out where RCM has "hyped OO"? I > > must have missed it, in the fifteen years or so I've been following > > his writings. (Now if you'd said "hyped XP", you'd have been on > > stronger ground :-)) > > > Best regards, > > Daniel > > I cannot give a specific quote at the moment, but it is typical OO > book argument-by-implication. > > For example, in chapter 7 he gives a typical device-driver-like > example of a "copy" program. He then shows how bad case/if statements > are for adding new devices and how polymorphism saves the day. It > does not state that this may or may not be relavent outside of device > drivers. There is no clear disclaimer anywhere I could find. > > The *implication* is that if poly is good here, it is good > *everywhere*. > > "Argument by narrow example" you could call this phenom. > > I wonder where OO would be without animal, shape, and device-driver > examples? If a judge forbid them, OO would probably be up pOOp creek. > > -T- > oop.ismad.com isn't this an example of what you are complaining about, i.e. claiming that Mr Martin has hyped OO using the most narrowest of narrow examples? because he doesn't subclause a simple example as not being universal then by implication all other claims he makes are thus similar?..... It's a bit weak.....I think you are reading far more into it than is there....and shooting yourself in the foot at the same time. |