SQL
in [OOP]
|
From: Mikito Harakiri on 19 Jan 2006 17:23 Patrick May wrote: > "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> writes: > > Patrick May wrote: > > > "topmind" <topmind(a)technologist.com> writes: > > > > Again, I have yet to see an objective or even semi-objective way to > > > > measure "complexity". > > > > > > I suggest you Google for "software complexity" and you'll > > > find several million links. Starting from a page like > > > http://yunus.hun.edu.tr/~sencer/complexity.html will give you > > > pointers to other research if you are genuinely interested in > > > learning. > > > > Hmm. I tried to find "software complexity" in wikipedia and failed. > > Apparently this topic (and the link you supplied) is a typical > > example of junk science. > > Apparently your research skills are on a par with your logic. > The point I was making is that there are objective measures of > software complexity. The most appropriate metrics vary depending on > the domain, environment, and other factors, but the metrics themselves > are objective. So if you can compare complexity of software, then perhaps you may suggest an objective criteria how to compare complexity of one TM vesus another? Isn't a problem formulated in terms of simple execution model (that is TM) supposed to be simpler than the same problem formulated in terms of programming languages (which are legacy artifacts)? > This is an area of active research, as you would know had you > done your homework before making spurious claims about "junk science." I made this opinion from the web reference that you supplied. Naive concepts everywhere ("Fan-In Fan-Out complexity"). No attempt to generalize. You can't just approach program complexity with accountant methods, you need some insights.
From: Oliver Wong on 20 Jan 2006 11:29 "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> wrote in message news:1137709389.246091.134930(a)o13g2000cwo.googlegroups.com... > > Patrick May wrote: >> "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> writes: >> > Patrick May wrote: >> > > "topmind" <topmind(a)technologist.com> writes: >> > > > Again, I have yet to see an objective or even semi-objective way to >> > > > measure "complexity". >> > > >> > > I suggest you Google for "software complexity" and you'll >> > > find several million links. Starting from a page like >> > > http://yunus.hun.edu.tr/~sencer/complexity.html will give you >> > > pointers to other research if you are genuinely interested in >> > > learning. >> > >> > Hmm. I tried to find "software complexity" in wikipedia and failed. >> > Apparently this topic (and the link you supplied) is a typical >> > example of junk science. >> >> Apparently your research skills are on a par with your logic. >> The point I was making is that there are objective measures of >> software complexity. The most appropriate metrics vary depending on >> the domain, environment, and other factors, but the metrics themselves >> are objective. > > So if you can compare complexity of software, then perhaps you may > suggest an objective criteria how to compare complexity of one TM vesus > another? Isn't a problem formulated in terms of simple execution model > (that is TM) supposed to be simpler than the same problem formulated in > terms of programming languages (which are legacy artifacts)? Mikito, this is another example of what I was talking about when I said what you're thinking when you see the word "software complexity" and what Patrick is thinking when he sees the word "software complexity" obviously differs. I called Patrick's semantics "real world" and yours "theoretical" because at the end of the day, a project lead working in a software development company for money is much more likely to be interested in Patrick's metrics than yours. Hell, even "Lines of Codes" is probably going to be a more interesting figure to him than the "Chaitin-Kolmogorov complexity of the binary representation of the program compiled for an Win32 x86 platform". I believe the "disagreement" between you two stems from this variance in definition of the terms you're discussing. - Oliver
From: Patrick May on 20 Jan 2006 15:25 "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> writes: > Patrick May wrote: > > The point I was making is that there are objective measures of > > software complexity. The most appropriate metrics vary depending > > on the domain, environment, and other factors, but the metrics > > themselves are objective. > > So if you can compare complexity of software, then perhaps you may > suggest an objective criteria how to compare complexity of one TM > vesus another? Isn't a problem formulated in terms of simple > execution model (that is TM) supposed to be simpler than the same > problem formulated in terms of programming languages (which are > legacy artifacts)? First, I'd like to apologize for leaping to flame you in my last post. It wasn't deserved or appropriate. You ask an interesting question, but not one that is really applicable to the point I was trying to make. The fact is that objective measures of software complexity do exist and additional metrics are under active development. None I know of are based on Turing Machines, but I suppose it is possible (although converting software written in Perl, for example, to a Turing Machine program in order to apply the metric would be . . . challenging). Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: Patrick May on 20 Jan 2006 15:27 "Oliver Wong" <owong(a)castortech.com> writes: > I called Patrick's semantics "real world" and yours > "theoretical" because at the end of the day, a project lead working > in a software development company for money is much more likely to > be interested in Patrick's metrics than yours. Very well put. I think you've identified the core issue. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: topmind on 21 Jan 2006 02:52
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > > The ability to model behavior as well as data makes general > > > purpose languages better able to model the problem domain than is > > > SQL. > > > > If you design right, you can *shift* much behavior to being data and > > DB operations instead. > > Depending on the requirements, some functionality can be > implemented using set operations, certainly. "Much" is pushing it, > especially when one limits oneself to non-gratuitous use of those > operations. I stand by that claim. However, as a warning in the end it turns into a Laynes Law mess tied to the definition of "data" versus "code" and/or behavior. > > > SQL is close to being Turing Complete. > > In other words, SQL is not Turing complete. That addresses your > original question: No, because I never claimed "all". > > > > > But how are tables less close to the domain than classes, > > > > methods, and attributes? > > We're done with that one. > > > Plus, OO is usually crappy at modeling behavior, at least in the biz > > domain. OO is only nice when things split up into nice hierarchical > > taxonomies. Most things don't in reality, so what is left is a mess. > > You've been challenged on this assertion in the past and failed > to defend it. The history is available via Google for anyone to see. > Unless you've got more to back up your nonsense than you did before, > repeating this is intellectually dishonest. My crappometer crapped out. The burden is not on me to prove that OO is better. It is on you. The default is equal or unknown. > > > > > > Proliferation of get/set methods is a code smell. > > > > > Immutable objects are to be preferred. > > > > > > > > This is not the censuses in the OO community. > > > > > > Yes, it is. Josh Bloch recommends immutability explicity in > > > "Effective Java" and gives solid reasons for his position. > > > Proliferation of getters and setters violates encapsulation, one > > > of the defining characteristics of object technology. Some > > > research will show you that OO designs focus on behavior, not > > > state. You should also check out the Law of Demeter and similar > > > guidelines that provide further evidence that excessive use of > > > accessors and mutators is not good OO form. > > > > Almost all of these have a fair amount of disagreement among OO > > proponents. Check out c2.com. > > Interesting. I provide explicit examples of what are generally > accepted as good OO principles and practices and you refer to a random > website. If you have real documentation of getter/setter > proliferation being an accepted OO technique, produce it. Do you have the opposite? > > > > > I would note that a lot of the issues you mentioned, such as > > > > performance, scalability, resiliency, and recoverability can be > > > > obtained by purchasing a "big-iron" RDBMS such as Oracle or > > > > DB2. The configuration and management of those issues is then > > > > almost a commodity skill and not as tied to the domain as a > > > > roll-your-own solution would be (which OO'ers tend to do). > > > > > > It is statements like this that strongly suggest that you > > > have never developed a large, complex system. > > > > No, because I break them up into peices so that they don't grow to > > be one big fat EXE. The Big-EXE methodology has a high failure rate. > > Modularity is not exclusive to imperative programming. It is > also not the silver bullet that slays the complexity lycanthrope. It works as well as anything else for biz apps. > > > > The vast majority of businesses that need systems of this > > > complexity have legacy software consisting of a number of COTS > > > applications and custom components, none of which were designed to > > > work with each other. These have been selected or developed for > > > good business reasons and cannot be aggregated and run on a single > > > piece of kit, no matter how large. > > > > Agreed, but what does the existence of legacy apps have to do with > > your scaling claim? > > The existence of legacy systems is just one reason why your > suggestion of using '"big-iron" RDBMS such as Oracle or DB2' cannot > solve the complex problems of large organizations. I am not following you here. If some of the processing has to be on legacy systems then it has to be on legacy systems. The introduction of a DB does not change that. BTW, I've encountered such systems were legacy info was converted to RDBMS data via periodic updates so that it could be used more easily. > > > I did not mean to suggest that everything should be centralized. > > That is what you suggested above. I didn't say it must be centralized. Perhaps I should have said "big iron(s)". That better? > > > It depends on the kind of business. If the vast majority of > > operations/tasks needed are per location, then regional partitioning > > works well. If not, then a more centralized approach is needed. For > > example, airline reservation and scheduling systems would make a > > poor candidate to partition by location because of the > > interconnectedness of flights. However, individual stores in a big > > franchise can operate most independently. > > Your lack of experience with large, complex systems is showing, > again. You always claim this. Offer evidence that your alternative is better instead of belittling people without evidence. That is rude and bad debating. Even a chimp can claim he/she is smart and a know-it-all. The hard part is demonstrating it. > Basically you're suggesting one or more monolithic processing > hubs -- the simple CRUD/USER stuff you're used to writ large. Are > those the only kinds of problems you're used to? What kind of apps do you have in mind? > > > > > "Security" is mostly just massive ACL tables. > > > > > > That is profoundly . . . naive. I strongly urge you to read > > > everything you can find by Bruce Schneir, join the cryptography > > > mailing list run by Perry Metzger, and not say another word about > > > security until you understand why your statement is so deeply > > > embarrassing to you. For a quick, very small taste of why ACL > > > tables don't even begin to scratch the surface of the problem, > > > read http://www.isi.edu/gost/brian/security/kerberos.html. > > > > I see no mention of ACL's there. > > That's my point. So if Mr. Schneir does not mention it, it is no good? > > > If you have a specific case of ACL's crashing and burning, post it > > here and let's take a look at it. (Note that there are a lot of > > variations of ACL's, so a flaw in one kind is not necessarily a > > general flaw in ACP concepts.) > > I never claimed that ACL's crash and burn. I said that ACLs > barely scratch the surface of the security requirements of a large > distributed system. Clearly you don't have any experience with such. Clearly you have no evidence to present. > > > Again, use evidence instead of patronizing insults. It is a bad > > habit of yours. > > I can see how my habits of calling bullshit when I smell it and > not suffering fools gladly would be considered "bad" by someone with > your proclivities. That doesn't change the fact that your claim that > "massive ACL tables" address the security requirements of large > distributed systems is ridiculous on its face. Patronization is the > best you can expect when you spew nonsense like that. Try something novel, like, say..........counter evidence? > > > > CRUD applications are, however, not particularly complex as > > > software systems go. Your claims otherwise indicate a lack of > > > experience with anything else. > > > > Again, please use evidence to prove me wrong instead of patronizing > > insults. It is a bad habit of yours. > > How is that patronizing? It's a simple statement of fact. There > is a reason why the CRUD work is typically given to new hires and > junior developers. You have a strange sense of biz apps. > > > Propose a way to measure "complexity", and then apply it to CRUD > > apps. That is how you make a point. Anecdotes and private personal > > opinions mean very little here. They are a dime a dozen. > > If you're seriously suggesting that CRUD applications are equal > in complexity to compilers, telco OSS/BSS, MRP/ERP, or risk analytics, > just to pull a few examples off the top of my head, then that reflects > more on your experience than on the veracity of your claim. Easier domain to learn, yes. Less complex, no. I stand by that unless you can come up with a decent measurement for complexity. Personal opinions are a dime-a-dozen. Evidence backing such opinions is rare, and certainly in the vacinity of you. The two candidate metrics proposed: code bulk and automatability, show biz apps not be measurably simpler. > > > > On the other hand, there are some delightfully complex > > > software systems that consist of only a few hundred lines of code. > > > Functional languages seem especially good for this. See one of > > > Peter Norvig's books for a few examples. > > > > Most FP demonstrations of such are "toy" or "lab" examples. > > Dismissing out of hand systems of which you know nothing. That's > a bad habit of yours. I gave them a chance to strut their stuff. If they can't strut right, it ain't my fault. > > I'd be tempted to ascribe your apparent need to continue > discussions ad nauseam to some form of obsessive-compulsive disorder, > but I don't have a background in psychology so I won't. You should > try that not-talking-about-things-you-know-nothing-about approach > sometime. Prove you are full of truth instead of claim it. Hey, weren't you blown away by others on your claim that "relational" was mostly about links? You never even admitted defeat. Stuburn to the stub you are. > > Sincerely, > > Patrick > -T- |