Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: topmind on 11 Feb 2007 15:51 Patrick May wrote: > "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. I told you that I am working on it and will take my sweet time. > > >> 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. MVC sucks IMO. The best GUI systems are a combination of attribute- driven and event-driven, similar to the VB/Delphi model, perhaps minus the unnecessary GUI config code. Indexability (findability) is what is needed, not really "decoupling". Decoupling only makes sense if you are likely to switch GUI systems, which is too rare to bother paying a constant complexity tax for. (Similar issue to switching DB vendors that OO'ers claims has to be done like every 6 months.) Again, indirection is not free. > > > 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. True, but the web killed them off because if its awkward event and response cycles. But still, the nitty details are often domain- specific or customer-specific. With good GUI tools you spend a few days designing the basics, but weeks or months customizing it based on customer feedback. > > > 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. But I've found that the web complicates the process by adding limitations to what can be practically accomplished. One then spends most of their time working around web limitations to fit needs instead of focusing on what the customer really wants/needs. It is like trying to swim without arms. The ideal GUI for the situation and the web version are often much further apart than with fat-desktop tools. > 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. Well, I am not in a mood to go hunt it down for you. > > > 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. It is one of many variables. Nobody has a consensus measure of simplicity. I would present my design, and one could see how that at least it is less lines of code. If readers want to claim it is more complex for whatever reason, fine. To my mind it is simpler and barring good objective metrics being found, *psychology* is what matters. Code is usually simpler *to me* when it uses the database as directly as possible. This is because there is less code spent on converting back and forth between relational/tables and navigational structures. I find navigational chaotic and messy in addition to the translation costs. So did Dr. Codd for that matter, so I am not alone. If I am a nutcase for that, than so is Dr. Codd. He won an ACM prize BTW, you didn't. Many of us do NOT like large-scale navigational. It does not fit our heads. If it fits yours, good for you, but don't force it down our throats using books that imply it is the only and best way in town. It wastes code and developer time to translate back and forth between navigational and relational. That is the best summary of the problem I can give you right now. OO is inharently navigational in structure (relationship between objects). > 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. I don't remember claiming I could objectively do so, beyond code size. > > >> 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 Perhaps off topic, but one could say the same about relational and other collection-oriented technologies such as APL and its newer cousins. (I've asked Lispers to show it significantly improving some sample code, and they admitted they couldn't do it, using lame evasive excuses.) > > 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*. It does when you are consider staffing and learning curves. > > > 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. Not necessarily. You create code that can only be understood by those schooled in multiple paradigms. This means that as long as the code exists, multi-paradigmers have to be hired. This will delay hiring (more time to find) and make them more expensive. Unless the benefits of doing such are significant, they will not outweigh the staffing drawbacks. You seem to be viewing this from a programmer's perspective, not a business owner's. Further, a certain percentage of such people use multiple paradigms as a form of Mental Masturbation. They mix techniques simply because they are bored or perhaps as a form of job-security lock-in, not because it results in more maintanable code. I've encountered people like this. It may be difficult to weed these out of the hirees and they will muck up designs. The further the technique is away from a manager's ability to verify, the more room for monkey business. > 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. Your opinion is not the majority opinion on this. > > > 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. We don't have a better word for mix of approaches at this point. '"Paradigm" is the best compromise word and everybody knows what it means even if not perfect. > > > 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? You come across as such an arrogant prick, you know that? I am at the point where people tell me I should go into management to avoid the well-known industry-wide age discrimination of programmers. General experience is not heavily valued in this industry, only experience in specific technologies needed by a given company. I am just the messenger, I didn't make it this way. Thus, the career incentive to become a multi-paradigmer is small. > > Sincerely, > > Patrick > -T-
From: Jerry Coffin on 12 Feb 2007 01:37 In article <1170945729.202845.75650(a)a34g2000cwb.googlegroups.com>, danielaparker(a)gmail.com says... > On Feb 7, 4:42 pm, "topmind" <topm...(a)technologist.com> wrote: > > > > It is also curious how Martin finds a way to work the latest software > > engineering buzzwords into his book titles, dispite the fact that the > > content and arguments do not change much. > > Curious indeed. I am sure that even RCM would take you seriously on > this point, recognizing your demonstrated expertise in "content and > arguments [that] do not change much" Much, or even at all. He hasn't come up with a new argument, or even much in the way of new wording, since I wrote this: http://groups.google.com/group/comp.object/msg/4b921df97d010b42 back in 2001. It's sad to re-subscribe, and see _precisely_ the reason I unsubscribed still happening, and from the same idiot at that. If nothing else, he could have the courtesy to learn the proper name for the specific type of fallacious reasoning he uses, and put "Argumentum ad Ignorantiam" in the title of each of his posts, to give a clear signal of the content. Fortunately, the "topmind" in the "from" is equivalent, since he seems to use no other tactic. For those who don't follow the latin bit, it's any argument based on the idea that something must be true because it hasn't been proven wrong. -- Later, Jerry. The universe is a figment of its own imagination.
From: topmind on 12 Feb 2007 12:07 Jerry Coffin wrote: > In article <1170945729.202845.75650(a)a34g2000cwb.googlegroups.com>, > danielaparker(a)gmail.com says... > > On Feb 7, 4:42 pm, "topmind" <topm...(a)technologist.com> wrote: > > > > > > It is also curious how Martin finds a way to work the latest software > > > engineering buzzwords into his book titles, dispite the fact that the > > > content and arguments do not change much. > > > > Curious indeed. I am sure that even RCM would take you seriously on > > this point, recognizing your demonstrated expertise in "content and > > arguments [that] do not change much" > > Much, or even at all. He hasn't come up with a new argument, or even > much in the way of new wording, since I wrote this: > > http://groups.google.com/group/comp.object/msg/4b921df97d010b42 > > back in 2001. It's sad to re-subscribe, and see _precisely_ the reason I > unsubscribed still happening, and from the same idiot at that. If > nothing else, he could have the courtesy to learn the proper name for > the specific type of fallacious reasoning he uses, and put "Argumentum > ad Ignorantiam" in the title of each of his posts, to give a clear > signal of the content. Fortunately, the "topmind" in the "from" is > equivalent, since he seems to use no other tactic. The burden is NOT on me to prove anything. OO is being shoved down the throats of developers everywhere without first EARNING the right to be king. I have received dozens of complaints from other developers who feel the same. The burden is on OO proponents to prove it objectively better for real software, or retract betterment implications. They have not. As far as complaints about OO criticism being off topic, until there is a group called something like "comp.object.criticism", comp.object *is* the proper topic for such. I am NOT violating any proper net etiquette. If you cannot handle criticism of your pet paradigms, then please do go away. Usenet is not for the faint of heart, with or without me. Anecdotal evidence does not go very far here, nor should it. (Although it is fair to counter anecdotal evidence with other anecdotes. But anecdotes are still a very weak form of evidence. They are the neutrino's of evidence.) In short, your complaint is without merit. If my criticism gives you headaches, then see a fricken doctor. Truth hurts. > > For those who don't follow the latin bit, it's any argument based on the > idea that something must be true because it hasn't been proven wrong. Which is what OO'ers imply. > > -- > Later, > Jerry. -T-
From: Patrick May on 13 Feb 2007 08:23 "topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> 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. > > MVC sucks IMO. What a surprise. > Decoupling only makes sense if you are likely to switch GUI systems, > which is too rare to bother paying a constant complexity tax for. Decoupling helps to address non-functional requirements such as maintainability, extensibility, scalability, and resiliency. Tightly coupled big balls of mud are an indicator of poor quality software. >> >> 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. > > Well, I am not in a mood to go hunt it down for you. Another failure to support even your most trivial of claims. I'm shocked. >> > 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. > > It is one of many variables. Nobody has a consensus measure of > simplicity. I would present my design, and one could see how that > at least it is less lines of code. If readers want to claim it is > more complex for whatever reason, fine. To my mind it is simpler > and barring good objective metrics being found, *psychology* is what > matters. It sounds like you're simply going to provide a highly coupled, big ball of mud and claim that fewer lines of code means it is simpler, ignoring your previous admission that lines of code is not a good metric and ignoring any of the benefits of the implementation you are comparing it to. Basically, I expect you'll address only a small portion of the functional and non-functional requirements addressed by Mr. Martin's example, but nonetheless claim victory in your own mind. Gee, I can hardly wait. >> 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. > > I don't remember claiming I could objectively do so, beyond code > size. You expressly agreed that code size is not a good measure of simplicity. >> Having fewer tools cannot result in higher quality software >> than having more tools and *knowing how to use them*. > > It does when you are consider staffing and learning curves. No, it cannot. If people don't know how to use the tools, they won't. Those who can, will use them and will train others. >> 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. > > Not necessarily. You create code that can only be understood by > those schooled in multiple paradigms. This means that as long as the > code exists, multi-paradigmers have to be hired. This will delay > hiring (more time to find) and make them more expensive. Unless the > benefits of doing such are significant, they will not outweigh the > staffing drawbacks. It's not that hard to find developers experienced with, or at least willing to learn, many different techniques. In fact, I would argue that such is part of the definition of "good developer". > You seem to be viewing this from a programmer's perspective, not a > business owner's. On the contrary, I'm looking at it from the perspective of providing high quality software with measurable business value. That requires good developers. > Further, a certain percentage of such people use multiple paradigms > as a form of Mental Masturbation. They mix techniques simply because > they are bored or perhaps as a form of job-security lock-in, not > because it results in more maintanable code. By definition, these are not good developers. They're just as foolish as those who limit themselves to a single set of techniques. >> 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. > > Your opinion is not the majority opinion on this. How fortunate for you. >> You're still hung up on the idea of "paradigms". Let it go. >> It's obscuring your view of the more cohesive, integrated reality >> beyond your self-limiting categories. > > We don't have a better word for mix of approaches at this point. > '"Paradigm" is the best compromise word and everybody knows what it > means even if not perfect. My point is that it obfuscates rather than illuminates. Think in terms of techniques and idioms, not arbitrary categories. >> 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? > > You come across as such an arrogant prick, you know that? Sticks and stones, Bryce baby, sticks and stones. My question is not entirely facetious. If someone came into an interview and whined "I only use relational techniques, that OO and functional stuff doesn't 'fit my brain.' I'm not interested in learning anything new, it'll just confuse me and make it harder for me to solve problems. And by the way, I like to make up my own words like 'betterment.'", I'd show him the door immediately. I can see why you try so hard to hide behind a pseudonym, and it has nothing to do with backlash against critics of OO. You constantly argue in favor of willful ignorance, intellectual laziness, and stupidity. Your lack of passion for learning shows that you do not have the hacker nature. C'mon, give it a chance. Stand in front of a mirror right now and say "You want fries with that?" Feels natural to you, doesn't it? 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: frebe on 13 Feb 2007 14:13
> >> >> 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. http://groups.google.com/group/comp.object/tree/browse_frm/thread/06ed010286143585/96af435ce565fe1a?rnum=81&_done=%2Fgroup%2Fcomp.object%2Fbrowse_frm%2Fthread%2F06ed010286143585%2F51231cc89eb34c3d%3F#doc_e72b316d3cbb8b11 Please try to read the arguments presented to you. You ask for supporting argumentation, but when presented to you, you simply ignore it. /Fredrik |