Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Chris Sonnack on 26 Aug 2005 14:39 topmind writes: >> I'm tired of debating with someone who, as far as I can tell, is >> either deliberately trolling or is totally clueless about what >> real programmers actually do and how real programs are actually >> written. > > [...] Like I keep saying, even many die-hard OO proponents agree > with me that trees and inheritance are oversold. I agree with that, too. But, despite your occasionally claiming that's your argument, that is NOT what you've been arguing. YOU have been arguing that trees are bad and wrong. THAT'S incorrect. >> You do appear to be what someone said early on: just >> a report writer. One step above a "power user". > > "Custom business applications". I did not say "report writer", Regardless. You simply don't talk like a programmer, and I've talked with programmers for 30 years, so I've seen all types. It's been clear from our discussion that you operate as a high level of, probably, putting components together, and therefore it's understandable why you don't follow many of my examples and don't understand the value of trees--particularly as data structures. > Anyhow, report writing is not necessarily simpler or harder than > other domains. I know you want to believe that, but--and we've covered this point before--it's just not true. REAL programming is harder. A lot harder. > If it was all easy and simple then most of it would be packaged > into boxed software that would do it all with a few clicks. Exactly. And a huge amount of it is. My group deals with a major application *designed* for businesses to use out of the box. > You appear to be turning to argument-by-intimidation instead of > presenting evidence that backs your stance. As I've said before, the only thing that could possibly intimidate you is being challenged to demonstrate that you do know what you are talking about. You've dodged every time. > If I was as retarded as you allege, you should be able to wipe > me all over the floor with good evidence and examples. As I said before, I believe an independant audit would show that I've done just that. You're just like a child who refuses to acknowledge cold, hard facts. I've challenged your knowledge. YOU'RE the one who's turned to personal insults several times. > You have not presented a very good case that trees are the ideal > data structure for almost everything. If you think that's been my position at any time during this thread, you've understood even less of it than I've suggested. I've never said it, I've never suggested it, I've never thought it. > Most of your complaints against sets appear to be that you don't > have a feel for how to navigate them. Nope. Not an issue. For one thing, I don't have any complaints about sets as sets. I use them as I do any tool--when they are appropriate. What I have argued against is your claim that they are always better. In fact, I've been doing in reality what you've been claiming (but in reality failing) to do: arguing against zealotry. Yours. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 27 Aug 2005 00:50 Chris Sonnack wrote: > topmind writes: > >> I dispute your "relational==table" definition, so I see not > >> one thing that makes this table "relational". It's just a > >> (what I'd call) "flat table". > > > > Well, my definition is correct. The history of > > "relational" is based on that usage. > > Then no doubt you can provide a reference beyond your mere > assertion. Even the example you just provided seems to show > that it takes a *relation* to be *relational*. No. I was showing that one can have links within the same table. But the links were not the main point being illustrated. That was to make an "ability" point, not a definition point. > > >> The line from that page, "In the relational model, formal > >> methods exist for quantifying "how normalized" a database is," > >> seems to suggest to me normalization is a fundamental part of > >> a relational database. > > > > Normalization is simply duplication factoring. The principle > > exists in just about every code or data organizational > > principle. In other words, it cuts across paradigms. > > But has a very *specific* meaning in relational databases. The normalization rules are pretty much *techniques* to remove duplication. One does not even have to undstand relational to identify the mere *existence* of duplication. Different paradigms may have their own set of techniques or rules-of-thumb for removing duplication. > > > >> But I do NOT see any relation to answering the question I asked. > >> Can you answer it, or were you just throwing words out randomly? > > > > Sorry, but I lost the context of this section of discussion. > > No, you didn't. It was IN the post you're replying to. In fact, > you quoted it in YOUR post. Here it is again: > > >You> However, there are different ways to interpret "duplication" for > >You> empty cells. Empty cells do not have to take up physical space, > >You> especially in "dynamic relational". > > >Me> Empty cells? Where did that come from? Are you talking about > >Me> NULL fields? Row duplication?? What??? > > > >>>> http://en.wikipedia.org/wiki/Relational_model > >>>> > >>>> It starts out, "The fundamental assumption of the relational > >>>> model is that all data are represented as mathematical relations,..." > >>>> ^^^^^^^^^ > >>>> Sounds interconnected to me. > >>> > >>> Well, it is misleading. The same link also says: > >>> > >>> "A table is an accepted visual representation of a relation; a > >>> tuple is similar to the concept of row." > >> > >> How, exactly, do you think that refutes the first quote? > > > > Maybe it doesn't. Either way it does not appear to support > > your assertation that "relation" means cross-table references > > in the context of relational. > > Don't create straw targets. I never said cross-table. But in the > interest of moving this along, perhaps there is a problem of lack > of precision in words here. > > By "interconnected" I mean one record referring to another via a > foreign key link to a primary key in another record--which, yes, > can be in the same table (*typically* not, but that's irrelevant). > > Where we may still disagree (?) is that, IMO, a "flat table", that > is a table with no relationships, is NOT relational. > > Hence "table" != "relational" The term "relational" has nothing to do with keys and their referencing stuff. I used to think it did, but like you now, I was wrong. You lost this one. > > > >> If the database moves to a different machine (with a different > >> name, obviously), then no. The ODBC setup must be tweaked for > >> the new hostname. > > > > The ODBC name is not the same thing as > > a "machine name". It is essentially the name of > > a configuration, a "reference" to a database (and usually a > > locally-stored configuration). > > Yes. And **IN** that configuration is the machine name. > If that changes, the configuration must change. Are you suggesting having the configuration point to yet *another* configuration that is virtual? It may be possible, but too much indirection can complicate maintanence just as much as too little. I don't think many DBA's would vote for yet another layer. > > > >> You want to store files in a database. What happens when > >> those files are very, very, very large? > > > > That is an implimentation detail. > > But a very significant one with regard to, um, implementing such > a system in the real world. > > > I don't know what the upper limits are on the leading vendor's > > products. > > Doesn't matter. What happens when I want to store the DB itself > in your virtual file system? You can't store a full ten-gallon > container inside another ten-gallon container, because there's > no room for the container itself. I perfectly agree that the current batch of RDBMS are not tuned to replace file systems as is. It would probably require that a DB engine be tuned for that specific purpose to be competative with tree filers. (Some say the IBM AS/400 does it, but I have not tested it myself.) > > >>>> Or consider this: in a FS, I can define a folder as publically > >>>> shared, read-only, and any file I drop in there is available > >>>> to those I've shared the folder to. I can casually share and > >>>> unshare files just by moving them in and out of the folder. > >> > >> [...] > >> Describe how you think an RDBMS would provide such a simple service. > > > > UPDATE folders SET shared=true WHERE [folder criteria] > > You've missed the point. This isn't about how to make a folder shared. > It's about the ease of--once having a shared folder--dropping files, > or copies of files, into that folder to share them. Or the ease of > removing them, or deleting the copies, to unshare them. Having a relational engine does NOT prevent having a one-click icon for the masses any more than a tree-based file system requires one to type MD or MAKEDIR or COPY. I did not propose that every file operation be done with SQL or a query language. > > >>> Just because you are not adept at non-tree searches does not mean > >>> the rest of us are also not. > >> > >> Okay, so describe how you would find Bob's old project files after > >> Fred was done changing the attributes? > > > > How is this any worse than changing tree paths to represent > > the newer changed information? > > Because, as I've said several times before, I can browse around the > file system looking for likely folders. (I know this to be true, > because I've done it!) > > I note that, in your reply, you didn't answer my question this time, > either. I'll ask it again. Bob's gone, Fred hates him, so he's > altered all Bob's attributes. > > How do you find the project file? > How is this any easier or worse than somebody changing a file path name? It is possible to change folder names, you know. In fact, Microsoft's file browser makes it too easy to change the name: you click in the wrong spot and you can truncate a folder name. If you argue that it is harder to change tree paths (making them "safer from tampering"), then you have proved my rigidity point anyhow. You are between a rock and a hard-place. Or in your case, a tree and a rock. > -- > |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | -T-
From: Dmitry A. Kazakov on 27 Aug 2005 05:19 On Fri, 26 Aug 2005 13:21:30 -0500, Chris Sonnack wrote: > Dmitry A. Kazakov writes: > >> 2. "good guys" is of course fuzzy. Technically either Captain Kirk or >> "good guys" or both should be fuzzy to get 0.85 instead of 1 or 0. Well, >> assuming Captain Kirk being a real man... (:-)) > > Right. But at some point the knife comes down and the system decides that > this fuzzy guy, Jim, has 85% membership in this fuzzy group "good guys". > > THAT is not fuzzy. No it is. There are two variants: 1. Jim is 0.85 good is an input (term). 2. It was inferred from other inputs among which there is some fuzzy Z. In both cases there is something (Jim or Z) which you cannot split up into crisp sets. Fuzziness cannot be obtained from crisp data. Neither can it be reduced to them. >> 3. But let's forget it and say "good guys" is crisp. That wouldn't change >> anything because Captain Kirk is still 0.85 in it. What does it *mean* to >> be 0.85 good? > > Simple. It means you're good most, but not all, of the time. (True for > most of us, I imagine.) Nope. Firstly, time is not a subject of set theory. You must be talking about some [stochastic] process, not a set. Secondly, this way you can come only to randomness, i.e. an additive set measure (probability.) And thirdly, this will give you nothing, but probabilities. Because you will be unable to answer even trivial questions like: if Stochastic Captain Kirk was 85% of the time good, will he be the next time? The answer will sound it will, 0.85 probably. "0.85 will" is nothing better than "0.85 is". You still have nothing in your hands. >> This meaning is the essence. It is uncertainty you cannot deal with in >> a crisp framework. You can do it only symbolically by postulating existence >> of uncertainty (either as randomness (0.85 = probability of), or as >> fuzziness (0.85 = possibility of), or as other set measure.) But you cannot >> look into that measure. You have to carry it with all the time. And all >> the answers will be in the terms of that measure. So in the end after all >> manipulations you still have: "it is 0.85 right." And? Is right or wrong? >> See? It is insoluble. > > But, like probability functions in Quantum Mechanics, as some point, to be > useful, you have to "collapse" the function into a decision. And as we know the decision (observation) will destroy the original system. You loose and falsify knowledge by doing that. The same effect exists in fuzzy systems too. > I can no longer quote from memory accurately, but to paraphrase Jim T. Kirk > himself, "TODAY we *decide* to be good." (Tomorrow I might phaser you. :) > > And computers--that is to say binary--can easily carry our 0.85 symbols > around until we need to do a calculation that determines whether Kirk > pushes the phaser button or the nice guy button. No. 1. You can say no more than there is some probability p that Kirk will do this or that. You cannot create a copy of Kirk, likewise you cannot have an exact copy of an electron. 2. The inputs you are using for your inference are uncertain. You have no access to Kirk's brain. You have nothing but observations, which themselves are either random or fuzzy. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Robert C. Martin on 27 Aug 2005 12:06 On Thu, 25 Aug 2005 14:18:31 -0500, Chris Sonnack <Chris(a)Sonnack.com> wrote: >Robert C. Martin writes: > >> Sort of. Fuzzy logic is 'set' logic where objects have 'partial' >> membership in sets. So, Captain Kirk is an 85% member of the set of >> all good guys, and a 15% member of the set of all bad guys. > >And, insofaras "85%" and "15%" and "good guys" and "bad guys" are >all (in this context) well-defined (not fuzzy), we're back where >we started. It's the membership that's fuzzy. The sets and elements themselves are discrete. Let's say we decide to invoke the 'kill' operation on all the members of the bad-guy set. Kirk is only a 15% member? Is he only 15% dead? Or does he have a 15% chance of being killed? This is similar to the position of an electron. An electron of known energy has a fuzzy membership in the set of all objects that are at position p. ----- Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 "The aim of science is not to open the door to infinite wisdom, but to set a limit to infinite error." -- Bertolt Brecht, Life of Galileo
From: Chris Sonnack on 21 Sep 2005 18:35
topmind writes: >>>> I dispute your "relational==table" definition, so I see not >>>> one thing that makes this table "relational". >>> >>> Well, my definition is correct. The history of >>> "relational" is based on that usage. >> >> Then no doubt you can provide a reference beyond your mere >> assertion. Even the example you just provided seems to show >> that it takes a *relation* to be *relational*. > > No. I was showing that one can have links within the > same table. But the links were not the main point being > illustrated. That was to make an "ability" point, not a > definition point. Why would you need to demonstrate an ability no one disputes? How about you back up your original claim "relational==table"? >>> Normalization is simply duplication factoring. The principle >>> exists in just about every code or data organizational >>> principle. In other words, it cuts across paradigms. >> >> But has a very *specific* meaning in relational databases. > > The normalization rules are pretty much *techniques* to > remove duplication. One does not even have to undstand relational > to identify the mere *existence* of duplication. No doubt, but you're dodging the point. Again. How about you stop waving your arms and address the actual point. (Now you'll claim you can't remember the original point.) >>>>>> http://en.wikipedia.org/wiki/Relational_model >>>>>> >>>>>> It starts out, "The fundamental assumption of the relational >>>>>> model is that all data are represented as mathematical relations,..." >>>>>> ^^^^^^^^^ >>>>>> Sounds interconnected to me. >>>>> >>>>> Well, it is misleading. The same link also says: >>>>> >>>>> "A table is an accepted visual representation of a relation; a >>>>> tuple is similar to the concept of row." >>>> >>>> How, exactly, do you think that refutes the first quote? >>> >>> Maybe it doesn't. Either way it does not appear to support >>> your assertation that "relation" means cross-table references >>> in the context of relational. >> >> Don't create straw targets. I never said cross-table. But in the >> interest of moving this along, perhaps there is a problem of lack >> of precision in words here. >> >> By "interconnected" I mean one record referring to another via a >> foreign key link to a primary key in another record--which, yes, >> can be in the same table (*typically* not, but that's irrelevant). >> >> Where we may still disagree (?) is that, IMO, a "flat table", that >> is a table with no relationships, is NOT relational. >> >> Hence "table" != "relational" > > The term "relational" has nothing to do with keys and their > referencing stuff. I used to think it did, but like you now, > I was wrong. You lost this one. Heh, so you say, but I say Michelle Pfeiffer secretly adores me. So, as you see, saying something has no connection with reality. EVERY resource I checked agrees. You have yet to produce anything other than arm waving to support your point. If you are right and I'm wrong, where's the proof? Should be easy enough to find. >>> The ODBC name is not the same thing as a "machine name". It >>> is essentially the name of a configuration, a "reference" >>> to a database (and usually a locally-stored configuration). >> >> Yes. And **IN** that configuration is the machine name. >> If that changes, the configuration must change. > > Are you suggesting having the configuration point to > yet *another* configuration that is virtual? No, I'm talking about how ODBC connections work. (Apparently this is yet another area of ignorance for you.) Under the hood of every ODBC connection is a machine name. >>>> Describe how you think an RDBMS would provide such a simple service. >>> >>> UPDATE folders SET shared=true WHERE [folder criteria] >> >> You've missed the point. This isn't about how to make a folder shared. >> It's about the ease of--once having a shared folder--dropping files, >> or copies of files, into that folder to share them. Or the ease of >> removing them, or deleting the copies, to unshare them. > > Having a relational engine does NOT prevent having a one-click > icon for the masses any more than a tree-based file system > requires one to type MD or MAKEDIR or COPY. I did not propose that > every file operation be done with SQL or a query language. Um, that's exactly what you DID propose above. How do you expect a one click icon to know what folder, what criteria? And once again, you've completely missed the real point. Which is, now that a shared folder exists, how do you move files and copies of files into and out of that "folder"? >> Because, as I've said several times before, I can browse around the >> file system looking for likely folders. (I know this to be true, >> because I've done it!) >> >> I note that, in your reply, you didn't answer my question this time, >> either. I'll ask it again. Bob's gone, Fred hates him, so he's >> altered all Bob's attributes. >> >> How do you find the project file? > > [...total non-answer...] Heh, you've got to be an ignorant fool or a troll. NO ONE could be this willfully stupid. I've hung into this thread because it was engaging and there was room to believe you were serious about this stuff, but at this point I think you're either a jackass or a troll or an idiot. I don't have time for any of them, so this will be my final post in this thread. You go right ahead and write your reports -- you're right you probably have very little use for trees in report writing. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| |