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 18 Feb 2007 13:30 "frebe" <frebe73(a)gmail.com> writes: >> > 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. More word games from the mad projector. You made a ridiculous claim and have provided no evidence or solid arguments in support of it. The burden of proof is yours. Now please describe exactly why you believe that relations are the only data structure that should be used. 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: AndyW on 18 Feb 2007 16:33 On Sat, 17 Feb 2007 19:51:26 -0500, Patrick May <pjm(a)spe.com> wrote: >"topmind" <topmind(a)technologist.com> writes: >> Patrick May wrote: >>> 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. >> >> It is a big juicy "it depends". > > No, it isn't. Tightly coupled big balls of mud are an indication >of poor quality software. Such might be justifiable for a one-off, >never to be modified, must have it in 10 minutes hack or a quick, >throwaway script that actually is thrown away. Other than these kinds >of cases, keeping your code clean pays off in even the very short >term. > What is software quality ? ---------------- AndyW, Mercenary Software Developer
From: topmind on 19 Feb 2007 00:43 Patrick May wrote: > "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. Just like your "big balls of mud" statement below? The "H" words comes to mind. > > 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. We are considering single use here. (Double-use is often borderline IMO, depending on the code.) > > >> As discussed elsewhere in the thread, even the hard of learning > >> Mr. Jacobs admits that lines of code is not a sufficient measure. Poor paraphrase. I agreed it was one factor among many that matter. > > > > 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? You go into brochure-mode here and redefine wrapping as "being clean" in a Carl Rovian way. Perhaps you should be in marketing, not software development. > > > 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. This is an argument-via-authority fallacy, not evidence. You need to turn "readily appearent" into something that can be publically inspected. I've also found that different things tend to help or hinder different people in different ways. Companies tend to hire like- minded people such that perhaps your viewpoint of what people like is tinted by this. It may also be the case with me, but I already agreed that pyschology is a big part of software engineering. > The "bloat" you claim > has yet to be demonstrated when comparing like with like rather than > your naive lines of code metric. He is pointing out at least one objective downside of SQL wrapping: more code if not reused multiple times. I have not seen you refute that numerically. You have yet to show an objective upside to counter it, let alone any clear argument devoid of marketing terms. You simply redefined wrapping as "being clean, and everyone agrees that clean is good". That is not debate, that is doing Carl Rove impressions. > > Sincerely, > > Patrick > -T-
From: panu on 19 Feb 2007 04:12 frebe wrote: > 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. If (most of) my files containing Java code do not hardcode SQL in them I can change my SQL without a chance of breaking my Java code, and vice versa. I might have to do this when I switch my database from MS to Oracle for example. Most programmers are either experts in SQL, or in Java, but not both. If SQL and Java -code are kept in separate files then each group of experts can work on their respective files, and be responsible for the correct functioning thereof. When two programmers work on the same file, neither is responsible. In construction, if Masons, Carpenters, Electricians, Engineers, all work on every problem together, regardless of their expertise - don't move to that building. Divide and Conquer! Put SQL-problem in its own file. Let the SQL programmers take care of it. -Panu Viljamaa
From: panu on 19 Feb 2007 05:21
Patrick May wrote: > "frebe" <frebe73(a)gmail.com> writes: >> 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. I agree with you. I think the issue somehow relates to the comparison between lots of text that is easy to read, and very little text that is hard to understand. Clearly there is a balance somewhere there between the extremes. Here the beauty of Patterns Kicks In. It's about accepting that nothing is black-and-white: There are FORCES which work against us trying to reach the ideal solution. Yet, if there is a pattern, there is also a (re)solution that balances those forces. MODULARITY is a pattern that resolves the conflict between writing code that is too long for anyone to understand as it takes 2 months to read it - and code that is too TERSE and cryptic to understand without spending 2 months studying the forgotten jargon of APL programmers. Modularity resolves the conflicting forces of LONGEVITY vs. OBSCURITY by dividing the problem into smaller sub-problems. If you can divide the top-problem into 10 sub-problems, each of which takes 2 hours to solve, your solution might take 2 * 10 = 20 hours. If you can not, your solution will probably take 10**2 = 100 hours. In other words DECOUPLED (= 'encapsulated') sub-problems add to the total effort required ARITHMETICALLY, whereas COUPLED (= tangled) sub-problems add to the total effort MULTIPLICATIVELY. The effort to solve them is the PRODUCT of each individual problem. I think experienced programmers and engineers know this by heart. Even Caesar did. -Panu Viljamaa |