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 17 Feb 2007 19:58 "frebe" <frebe73(a)gmail.com> writes: >> >> >> 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. Nothing in that post proves his claim. The closest you come is saying that shorter code is simpler. As discussed elsewhere in the thread, even the hard of learning Mr. Jacobs admits that lines of code is not a sufficient measure. The techniques used to decouple components and avoid big balls of mud offer significant benefits, particularly in addressing non-functional requirements. A tightly coupled big ball of mud that has fewer lines of code is not solving the same problem and is therefore not a proper "simplification" of the solution being critiqued by Bryce. Please try to keep up with the thread before offering your smarmy comments. 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 18 Feb 2007 01:20 > >http://groups.google.com/group/comp.object/tree/browse_frm/thread/06e... > > > Please try to read the arguments presented to you. You ask for > > supporting argumentation, but when presented to you, you simply > > ignore it. > > Nothing in that post proves his claim. The closest you come is > saying that shorter code is simpler. So, you agree that decoupling SQL statements from the rest of the applications causes more bloated code? > As discussed elsewhere in the > thread, even the hard of learning Mr. Jacobs admits that lines of code > is not a sufficient measure. More lines of code takes longer time to write. More lines of code makes the code harder to read. There are other factors too, but that doesn't change the fact that LOC are important. > The techniques used to decouple > components and avoid big balls of mud offer significant benefits, > particularly in addressing non-functional requirements. Can you prove this claim? The benefits of decoupling SQL has to be considered unknown until someone can prove them. But the disadvantages (more bloated code) are easy to prove and has to be accepted as facts. /Fredrik
From: Thomas Gagne on 18 Feb 2007 08:47 frebe wrote: > <snip> >> The techniques used to decouple >> components and avoid big balls of mud offer significant benefits, >> particularly in addressing non-functional requirements. >> > > Can you prove this claim? > > The benefits of decoupling SQL has to be considered unknown until > someone can prove them. But the disadvantages (more bloated code) are > easy to prove and has to be accepted as facts. > What would you consider proof? If LOC remained constant but modularity increased, would that be proof? If LOC was constant and testability increased, would that be proof? If LOC remained constant but portability increased, would that remain constant? -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: frebe on 18 Feb 2007 12:18 > >> The techniques used to decouple > >> components and avoid big balls of mud offer significant benefits, > >> particularly in addressing non-functional requirements. > > > Can you prove this claim? > > > The benefits of decoupling SQL has to be considered unknown until > > someone can prove them. But the disadvantages (more bloated code) are > > easy to prove and has to be accepted as facts. > > What would you consider proof? Maybe you should ask Mr May instead. He started this "proof" game. Some good arguments is the only thing I really ask for. > If LOC remained constant but modularity > increased, would that be proof? If LOC was constant and testability > increased, would that be proof? If LOC remained constant but > portability increased, would that remain constant? The fact that LOC increases if you always have to wrap all SQL statements is already shown (obviously functions will decrease LOC if they are used when it is suitable, but that is not the question). So if you want to claim that LOC is constant, I suggest that you show why my previous argumentation about increasing LOC is invalid. The question is if the disadvantage with bloated code, is smaller than the possible advantages with wrapping all SQL statements in a separate layer. So, a good argumentation why wrapping a standardized language would increase portability, or why yet another layer would increade modularity, would be welcome. /Fredrik
From: Patrick May on 18 Feb 2007 13:29
"frebe" <frebe73(a)gmail.com> writes: >> > Please try to read the arguments presented to you. You ask for >> > supporting argumentation, but when presented to you, you simply >> > ignore it. >> >> Nothing in that post proves his claim. The closest you come >> is saying that shorter code is simpler. > > So, you agree that decoupling SQL statements from the rest of the > applications causes more bloated code? Since you're so fond of accusing others, baselessly, of playing word games, I will point out that your use of the term "bloated" is pejorative. Based on your posting history, I believe it to be deliberately so. Decoupling SQL statements may or may not increase the total number of lines of code, depending on the size of the SQL statements and the number of times they are reused. >> As discussed elsewhere in the thread, even the hard of learning >> Mr. Jacobs admits that lines of code is not a sufficient measure. > > More lines of code takes longer time to write. More lines of code > makes the code harder to read. This is not always, or even often, the case. Highly coupled big balls of mud that mix different concerns are more difficult to understand than well-factored, clean code. >> The techniques used to decouple components and avoid big balls of >> mud offer significant benefits, particularly in addressing >> non-functional requirements. > > Can you prove this claim? Maintainability and extensibility are two NFRs that come immediately to mind. Clean code is easier to maintain and extend. Reliability is increased when code is designed to be easily testable, another characteristic of clean code. Horizontal and vertical scalability benefits from having clearly defined, decoupled components. Security is easier to implement and prove when components have single responsibilities. Are you arguing that clean, well-designed code does not have quality benefits? > The benefits of decoupling SQL has to be considered unknown until > someone can prove them. But the disadvantages (more bloated code) > are easy to prove and has to be accepted as facts. The benefits are readily apparent to anyone who has developed any large, or even mid-sized, enterprise system. The "bloat" you claim has yet to be demonstrated when comparing like with like rather than your naive lines of code metric. 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) |