Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: Daniel Parker on 8 Feb 2007 14:29 On Feb 8, 1:16 pm, "topmind" <topm...(a)technologist.com> wrote: > > Gee, some of my other OO enemies call me waffling, inconsistent, etc. > When one's enemies hate one for contradictory reasons, it must mean > one is on to something... > Enemies? Hate? Where did that come from? As a priest told his congregation recently over the Christmas holidays, everyone is a source of joy: some when they arrive, others when they depart. Besides, there is no contradicton: everyone thinks you're waffling and inconsistent, and everyone thinks that your arguments, such as they are, don't change. Best regards, Daniel
From: topmind on 8 Feb 2007 15:53 On Feb 8, 11:29 am, "Daniel Parker" <danielapar...(a)gmail.com> wrote: > On Feb 8, 1:16 pm, "topmind" <topm...(a)technologist.com> wrote: > > > Gee, some of my other OO enemies call me waffling, inconsistent, etc. > > When one's enemies hate one for contradictory reasons, it must mean > > one is on to something... > > Enemies? Hate? Where did that come from? It's hyperbole (gee, where've we heard that?). "Debate participants who often disagree with me" if you will. > As a priest told his > congregation recently over the Christmas holidays, everyone is a > source of joy: some when they arrive, others when they depart. > Besides, there is no contradicton: everyone thinks you're waffling > and inconsistent, and everyone thinks that your arguments, such as > they are, don't change. Show me a material contradication. Surely with all my (alleged) repetition, you should readily have one to present. > > Best regards, > Daniel -T-
From: Patrick May on 8 Feb 2007 21:55 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> >> > 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. > > Above YOU implied that staying close to the DB was fine for "CRUD" > apps, but not for "more complex behavior". No, I agreed that using a database for simple create, read, update, and delete operations, all directly supported by straightforward SQL, made sense. The same clear overlap does not exist between complex business requirements and database functionality. You made the claim that using the database features will simplify the design relative to using OO techniques, without restricting the context of that claim. You therefore have the burden of proof to support that claim in the context of behavior more complex than simple CRUD. > You appear to be more interesting in playing word games than > interested in figuring out why people say such and such is good. Accusing your opponent of your own faults is known as projection. You do nothing but play word games, making bold claims, squirming, and finally refusing to meet the demands of intellectual integrity by either retracting or supporting your assertions. Prove your claim regarding simplification 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. > > All this mixing paradigm stuff is irrelavent anyhow. You are essentially arguing that ignorance is preferable to knowledge. You are also ignoring the fact that "paradigms" are somewhat arbitrary and not mutually exclusive. Do you honestly believe that having fewer tools available leads to higher quality software than having more tools? 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 9 Feb 2007 01:58 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Patrick May wrote: > >> >> > 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. > > > > Above YOU implied that staying close to the DB was fine for "CRUD" > > apps, but not for "more complex behavior". > > No, I agreed that using a database for simple create, read, > update, and delete operations, all directly supported by > straightforward SQL, made sense. The same clear overlap does not > exist between complex business requirements and database > functionality. Well, either way, you have not presented evidence of the DB getting in the way for typical biz apps; simple, CRUD, or complex. There is no "getting in the way" evidence so far. > > You made the claim that using the database features will simplify > the design relative to using OO techniques, without restricting the > context of that claim. You therefore have the burden of proof to > support that claim in the context of behavior more complex than simple > CRUD. I have no idea how you are measuring "complex". CRUD screens can often be complex because the rules for what, when, how, and where to display stuff can be sticky and involve a lot of nitty gritty biz rules. If CRUD was truly simple, then it would be packaged in easy libraries or tools such that they could be wipped out in half-a-day. However, good interface design is often difficult and requires trial and error, and lots of nitty gritty rules and exceptions to the rules if you want to give the customer a good product. Getting something up and running can be done fairly easy with RAD tools, but often the results are not very effective. It is sometimes said that RAD tool make the first 80% of the job a snap, but the last 20% nearly impossible. They get you "almost there" fast, but then bog you down. Give an example of this unicorn that busts DB's or I will lump it with bigfoot on the Existence Scale. > > > You appear to be more interesting in playing word games than > > interested in figuring out why people say such and such is good. > > Accusing your opponent of your own faults is known as > projection. You do nothing but play word games, making bold claims, > squirming, and finally refusing to meet the demands of intellectual > integrity by either retracting or supporting your assertions. > > Prove your claim regarding simplification or retract it. Freeb already gave one. Wrapping is objectively more code for single- use SQL than in-line. And similarly, an IF or case statement connected to a database attribute is objectively less code than a single-use polymorphic dispatch on the same attribute. > > >> >> 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. > > > > All this mixing paradigm stuff is irrelavent anyhow. > > You are essentially arguing that ignorance is preferable to > knowledge. You are also ignoring the fact that "paradigms" are > somewhat arbitrary and not mutually exclusive. No, I am arguing it is irrelavent to OO versus relational. If you want to argue for Functional or Prolog-logic, go for it, but not here. > > Do you honestly believe that having fewer tools available leads > to higher quality software than having more tools? Having more *by itself* does not automatically improve it, you would probably agree. As far as whether it *can* improve it if done right, it is hard to say. It cost brain power and training to switch back and forth between paradigms and changing code from one paradigm to another is costly when domain requirements take away a given paradigm's advantage for a given spot of code. There is probably a point of diminishing returns such that the skill to know and read multiple paradigms becomes more of a drag than having more options adds. If programmers lived 500 years and were not pressured to leave the profession after 42, the situation might be different. My concern is whether heavy use of OO noticably and objective improves biz apps. I've seen no evidence of such. > > Sincerely, > > Patrick > -T-
From: Patrick May on 11 Feb 2007 09:13
"topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> No, I agreed that using a database for simple create, read, >> update, and delete operations, all directly supported by >> straightforward SQL, made sense. The same clear overlap does not >> exist between complex business requirements and database >> functionality. > > Well, either way, you have not presented evidence of the DB getting > in the way for typical biz apps; simple, CRUD, or complex. There is > no "getting in the way" evidence so far. Your squirming is getting repetitive (and old). You made the claim that "If you embraced the DB instead of spend all your code wrapping it, the app would be noticably simpler." Let's see your proof. >> You made the claim that using the database features will >> simplify the design relative to using OO techniques, without >> restricting the context of that claim. You therefore have the >> burden of proof to support that claim in the context of behavior >> more complex than simple CRUD. > > I have no idea how you are measuring "complex". Do you have no experience with anything other than CRUD systems? > CRUD screens can often be complex because the rules for what, when, > how, and where to display stuff can be sticky and involve a lot of > nitty gritty biz rules. It sounds like you need to learn some patterns for decoupling your presentation and business rules. Look up MVC and some more recent enhancements. Careful, though, that might be getting dangerously close to the "OO Paradigm" for your taste. > If CRUD was truly simple, then it would be packaged in easy > libraries or tools such that they could be wipped out in half-a-day. Many can. The basic functionality of CRUD was among the first automated tools available. > However, good interface design is often difficult and requires trial > and error, and lots of nitty gritty rules and exceptions to the > rules if you want to give the customer a good product. Amazing, an entire sentence in which you've made a valid point. Yes, good interface design is difficult. Yes, a good UI designer is worth his weight in pizza. However, the complexity involved in creating good UIs and reports has more to do with the tools available and the more artistic nature of the work than with any software development issues. Considering only business UIs (games being a different matter entirely), the programming challenges are limited to tweaking and fiddling. The real complexity lies in the design of the user experience, most of which is outside the realm of code. In any case, this is a tangent that has nothing to do with your still unsupported claim. >> Accusing your opponent of your own faults is known as >> projection. You do nothing but play word games, making bold >> claims, squirming, and finally refusing to meet the demands of >> intellectual integrity by either retracting or supporting your >> assertions. >> >> Prove your claim regarding simplification or retract it. > > Freeb already gave one. I've seen no such thing. It's very easy for you to claim it, but without a reference to a specific section in a specific post, it's no more supported than any of your other claims. > Wrapping is objectively more code for single- use SQL than > in-line. And similarly, an IF or case statement connected to a > database attribute is objectively less code than a single-use > polymorphic dispatch on the same attribute. You agreed earlier in this thread that lines of code is not the only measure of simplicity. In order to support your claim, you need to demonstrate a solution that "embrace[s] the DB" and is simpler by some well-defined metric while still providing the same functionality and benefits of the implementation you are critiquing. >> Do you honestly believe that having fewer tools available >> leads to higher quality software than having more tools? > > Having more *by itself* does not automatically improve it, you would > probably agree. "Lisp is worth learning for a different reason — 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." -- Eric Raymond The same is true for most other languages and techniques, although obviously to a lesser degree. Having fewer tools cannot result in higher quality software than having more tools and *knowing how to use them*. > As far as whether it *can* improve it if done right, it is hard to > say. It cost brain power and training to switch back and forth > between paradigms It's not at all hard to say. Better developers manage to work with multiple paradigms simultaneously, choosing the techniques best for the problem at hand. Anyone who can't learn how to use at least one each of a procedural, object oriented, declarative, and functional language with a reasonable level of competence isn't anyone I'd hire. > and changing code from one paradigm to another is costly when domain > requirements take away a given paradigm's advantage for a given spot > of code. You're still hung up on the idea of "paradigms". Let it go. It's obscuring your view of a the more cohesive, integrated reality beyond your self-limiting categories. > There is probably a point of diminishing returns such that the skill > to know and read multiple paradigms becomes more of a drag than > having more options adds. If programmers lived 500 years and were > not pressured to leave the profession after 42, the situation might > be different. If you find that task of learning new techniques and approaches particularly onerous, perhaps you aren't in the right industry for your talents. Have you considered a career in food service? 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) |