Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Chris Sonnack on 21 Sep 2005 18:32 topmind writes: >> In fact, I've been doing in reality what you've been claiming (but >> in reality failing) to do: arguing against zealotry. Yours. > > Yeah right. The problem is me. Sure indeed. [shrug] Seems so. I'm not the one who just used an entire post to tender little but childish insults. I'm not the one who's utterly failed to understand basic programming principles or simple examples (your failure to grasp basics is once again evident in the other post to this thread). > [snip of irrelevant material, dogma and insults] > > Your examples did NOT demonstrate any inharent tree-nees to the > world and often I found flaws that you sweeped under the rug. The few you actually understood you waved your arms and CLAIMED there were flaws, but you didn't do much towards providing any proof. (See, it takes more than assertions to make a point--it takes examples and analysis to back it up. That's what you repeatedly fail to provide.) The others you never understood despite repeated attempts to make them clear. Not surprising, I guess, now that we've established that you never were a programmer in the first place. For example: > For example, the function calls. They bust your damned tree > into a graph yet you refuse to acknolege that. If you actually understood what a run time call graph was you'd realize instantly it's a tree--even a pure tree by your twisted definition of "pure tree". But since you never did understand it, the best you can do is act like a 12-year-old: > Graph graph graph! Eat it! Whatever. >> and don't understand the value of trees--particularly as data >> structures. > > Until I see them donstrated to have real value in my domain, I > will avoid them except on a small scale. As I've said before, for a report writer--as opposed to a real programmer--there probably ISN'T much value in tree-shaped taxonomies, although there might be in tree-shaped data. I know I've created reports that returned hierarchical data. Perhaps you never have. >>> 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. > > You are coming across as an arrogant prick. At least I know what I'm talking about. You so obviously don't. > How the hell do you define "real programmer"? Someone who actively writes code. Someone who understand analysis and design. Someone who understands data structures. Someone who knows AT LEAST three or four languages well. You fail on all counts, report writer. >> Exactly. And a huge amount of it is. My group deals with a major >> application *designed* for businesses to use out of the box. > > Why not point us to its website? All our installations are internal, so you can't access ours, but if you go ogle for major CRM vendors and pick the top one, you'll probably have it. >> 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. > > No, YOU have. You're doing it again in this post. Wasting time being a child. > You have failed to present anything that is natural tree at a > large scale in the biz domain. You have simply not showed it. Sorry, I just don't know how to explain "red" to a blind man. > Your "event-driven" startup drivel was laughable. Failing to understand it, you laugh at it. Typical. > You conveniently redefined "sequence" as being hierarchical. > "A" happening before "B" does NOT make anything hierarchical. Which just demonstrates how badly you misunderstood the example. As I recall, I had to explain several times before you even got close to an understanding, but close was the best you could do. >> I've challenged your knowledge. >> YOU'RE the one who's turned to personal insults several times. > > An independant audit would show that you started it first. I very much doubt that, since it's not at all my style. >>> 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. > > Then what are some examples where they fail and why do they fail in > those circumstances? I don't see any careful analysis from you, only > dogma. You've never heard word one of dogma from me--that also is not my style. I challenge you to go find something I said you consider dogma. I'm not the one with the "Life is not tree-shaped" mantra. >> 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. > > Which is? Why am I bother to explain this to someone who apparently doesn't even grasp basic set theory (or at least whined about intimidation when I challenged you)? But, once more, sets are fine when the data is sequential or unordered. When the data is table-like, a table or matrix is a good bet. And when the data is hierarchical, trees are a natural. > TREES JUST PLAIN DON'T SCALE. See, now THAT is just dogma. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Christian Brunschen on 22 Sep 2005 03:19 In article <71n3j19r9fpj6ij591a2pj7vacj2h80cau(a)4ax.com>, Chris Sonnack <Chris(a)Sonnack.com> wrote: >topmind writes: > >> 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. Let me quote from "An Introduction to Database Systems, Volume 1, Fifth Edition" by C. J. Date (Addison-Wesley, 1990) - this book, in its various editions (which include several ones thhat are newer than the one I own, of course), is often considered _the_ textbook on databases - on page 112, just at the beginning of section 4.2: <quote> <emphasis> A relational database is a database that is percieved by its users as a collection of trables (and nothing but tables) </emphasis> . </quote> And later on, starting at the bottom of page 115 and continuing onto page 116: <quote> At this point, the reader may be wondering why relational databases are called "relational" anyway. The answer is simple: "Relation" is just a mathematical term for a table (to be precise, a table of a cedrtain specific kind - details to follow in Chapter 11). [ ... ] In this part of the book, in fact, we will generally use the terms "relation" and "table" interchangeably, as if they were synonymoss. [ ... ] If it is true that a relation is basically just a table, then why not simply call it a table and have done with it? The answer is that (as already indicated) we very often do. However, it is worth taking a moment to understand why the term "realtion" was introducecd in the first place. briefly, the explanation is as follows. As already mentioned, relational systems are based on an underlying set of theoretical ideas knows as the <emphasis> relational model </emphasis. The principles of the relational model were originally laid down by one man, Dr. E. F. Codd, at the time a member of the IBM San Jose Research Laboratory [ ... ] . it was late in 1968 that Codd, a mathematiccian by training, first realized that the discipline of mathematics could be used to inject some solid principles and rigor into a field - database management - that, prior tothat time, was all too deficient in any such qualities. Codd's ideas were first published in a now classic paper, "A Relational Model of Data for Large Shared Data Banks") [ ... ] . Mow, the relational model as orginally formulated by Codd very deliberately made use of certain terms - such as the term "relation" itself - that were not familiar in data processing circles at the time, even though the concepts in some cases were. The trouble was, many of the more familiar terms were very vague and fuzzy. They lacked the precision necessary to a formal theory of the kind thaat Codd was proposing. For example, consider the term "record". At different times that single term can mean either a record <emphasis> instance </emphasis> or a record <emphasis> type </emphasis> [ more examples deleted ] . The formal theory therefore does not use the term "record"at all; instead, it uses the term "tuple" (short for "n-tuple"), which was given a precise definition by Codd when he first introduced it. We do not give that definition here; for our purposes in the present part of the book, it is sufficient to say that the term "tuple" corresponds approximately to the notion of a <emphasis> flat record instance </emphasis> (just as the term "relation" corresponds approximately to the notion of a table). [ ... ] </quote> The Codd paper refered to in the quoted text is: E. F. Codd. "A Relational Model of Data for Large Shared Data Banks." CACM 13, No 6 (June 1970). Republished in 'Milestones of Research - Selected Papers 1958 - 1982' (CACM 25th Anniversary Issue), CACM 26, No 1 (January 1983). In Chapter 11, 'Relation Structure', the book introduces formal definition for each term, which I will not quite here; but I will quote form the introduction to the chapter, on page 249: <quote> [ ... ] We explain each termver informally here [ ... ] : * A _relation_ corresponds to what so far in this book we have generally been calling a table. * A _tuple_ corresponds to a row of such a table and an _attribute_ to a column. The number of tuples is called the _cardinality_ and the number of attributes is called the _degree_. [ ... ] </quote> So, without attempting to validate or invalidate anything else on any side of any argument, according to what I have quoted above, it should be fairly clear that the term 'Relational' in 'Relational Database' has _nothing_ to do with relationships between different tables: The term 'Relation' is instead a different, more precise term for the type of tables used in Relational databases. So, even a database with only a single table, is a relational database. So, can we please put this particular issue to rest? Best wishes, >-- >|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | >|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | >|_____________________________________________|_______________________| // Christian Brunschen
From: Dusty Bin on 22 Sep 2005 06:55 Christian Brunschen wrote: <snip> </snip> > So, without attempting to validate or invalidate anything else on any side > of any argument, according to what I have quoted above, it should be > fairly clear that the term 'Relational' in 'Relational Database' has > _nothing_ to do with relationships between different tables: true The term > 'Relation' is instead a different, more precise term for the type of > tables used in Relational databases. So, even a database with only a > single table, is a relational database. The relationship is the relation between the columns of a table. hth... Dusty <snip>
From: Chris Sonnack on 22 Sep 2005 21:06 Ah, at last, an intelligent answer from someone who appears to know what they're talking about! Cool!! Christian Brunschen writes: >>> 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. >> >> 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. > > Let me quote from "An Introduction to Database Systems, Volume 1, Fifth > Edition" by C. J. Date (Addison-Wesley, 1990) - > > <quote> > At this point, the reader may be wondering why relational databases are > called "relational" anyway. The answer is simple: "Relation" is just a > mathematical term for a table (to be precise, a table of a cedrtain > specific kind - details to follow in Chapter 11). Ah ha. A certain specific KIND of table. Okay, let's skip to Ch.11.... (Given what you say far below, it appears the next bit isn't from the vaulted Chapter 11, so I'm trimming without mercy here....) > The principles of the relational model were originally laid down by one > man, Dr. E. F. Codd, at the time a member of the IBM San Jose Research > Laboratory [ ... ] . it was late in 1968 that Codd, a mathematiccian > by training, first realized that the discipline of mathematics could be > used to inject some solid principles and rigor into a field - database > management - [...]. Codd's ideas were first published in a now classic > paper, "A Relational Model of Data for Large Shared Data Banks") [ ... ] You know, maybe we should just go to the source: http://www.acm.org/classics/nov95/toc.html > The formal theory therefore does not use the term "record"at all; > instead, it uses the term "tuple" (short for "n-tuple"), which was > given a precise definition by Codd when he first introduced it. [...] > it is sufficient to say that the term "tuple" corresponds approximately > to the notion of a <emphasis> flat record instance </emphasis> (just > as the term "relation" corresponds approximately to the notion of > a table). You notice the use of "approximately" twice? > In Chapter 11, 'Relation Structure', the book introduces formal definition > for each term, which I will not quite here; Aw, why not? > but I will quote form the introduction to the chapter, on page 249: Hey, better'n nothing! > <quote> > [ ... ] > * A _relation_ corresponds to what so far in this book we have generally > been calling a table. Ahem, "have GENERALLY been calling a table." > * A _tuple_ corresponds to a row of such a table [...] > </quote> And the meat of this lies in the definition of a tuple. And, after reading Codd's paper (link above), I'll agree that his definition of a "relation" does show a single table that--from his example in section 1.3--containing records not **obviously** linked. However, I suspect this is similar to a code fragment and only shows a partial picture of the whole. After all, I don't know any suppliers named "1", "2" or "4". (A few paragraphs later he talks about "relationships", so I think there's still some wiggle room here! :-) > So, [...] it should be fairly clear that the term 'Relational' in > 'Relational Database' has _nothing_ to do with relationships between > different tables: Which I never claimed it was. I had to go read the back thread to recall how this started, but it began over a disagreement whether SQL was a "relational language". I suggested it would work perfectly well in a non-relational database containing a single (non-related) flat table. And turned into a mini-war from there. I stand by the original seed: SQL is not a "relational language". I also stand by the idea that "relational", in "Relational Database" is about *relationships* between records. I claim that if there are no relationships, there's no Relational. > The term 'Relation' is instead a different, more precise term for > the type of tables used in Relational databases. Exactly. Pay attention to the words: "...the TYPE of tables." Not just you plain old tables, but (as quoted above), " table of a cedrtain [sic] specific kind". VERY important distinction. Here's what I wrote over a month ago: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's a table (first row headers): NAME UID COLOR DATE TYPE Alice - Blue 5-3-1948 BG45 Bob - Red 5-3-1948 XL220 Carol 3345 Red 12-7-1955 E30F Dave 7709 Green 9-14-2000 - 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". Given something containing this table that also supported SQL, you could write: Select NAME,COLOR from TABLE order by NAME ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > So, even a database with only a single table, is a relational > database. Only if it's a certain *specific* *type* of table. (-: -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 23 Sep 2005 01:24
> > > For example, the function calls. They bust your damned tree > > into a graph yet you refuse to acknolege that. > > If you actually understood what a run time call graph was you'd > realize instantly it's a tree--even a pure tree by your twisted > definition of "pure tree". NOT! It has to turn reference into duplicate nodes to force tree-ness. Normalized, it would NOT be a tree. If you don't see the duplication, you are stubborn or blind. > > But since you never did understand it, the best you can do is > act like a 12-year-old: A 12-year-old who happens to be correct. Neener neener tree f8ck! > >> and don't understand the value of trees--particularly as data > >> structures. > > > > Until I see them donstrated to have real value in my domain, I > > will avoid them except on a small scale. > > As I've said before, for a report writer--as opposed to a real > programmer--there probably ISN'T much value in tree-shaped taxonomies, > although there might be in tree-shaped data. I know I've created > reports that returned hierarchical data. Perhaps you never have. The hierarchical nature of such reports is a particular *view*. The arrangement of the tree can often be changed. For example, one can nest products sold by region, or regions per product. Region A product 1 product 2 product 3 Region B product 1 product 2 ..... OR Product 1 region A region B region C Product 2 region A ... In the old days (read about IMS) the databases hard-wired the hierarchies into its structure. If a particular report was by the same tree, it was okay. If not, you had to bend over and scratch your back with your tongue. > >> Exactly. And a huge amount of it is. My group deals with a major > >> application *designed* for businesses to use out of the box. > > > > Why not point us to its website? > > All our installations are internal, so you can't access ours, but if > you go ogle for major CRM vendors and pick the top one, you'll probably > have it. I have worked with the databases of companies that have tens of millions of customers, and generally they base their classification systems on sets. In fact, some of the biggest problems happened from hierarchical arrangments set up in the days when they were much smaller. The trees failed to scale and they had to overhaul them. For example, they are shifting from "levels" to prequisites based on sets to match which products must be sold together. Levels were sufficient when their product base was small. However, customers want more al-la-carte choice. > > > Your "event-driven" startup drivel was laughable. > > Failing to understand it, you laugh at it. Typical. > > > You conveniently redefined "sequence" as being hierarchical. > > "A" happening before "B" does NOT make anything hierarchical. > > Which just demonstrates how badly you misunderstood the example. > As I recall, I had to explain several times before you even got > close to an understanding, but close was the best you could do. Let's leave it to the reader to decide whither sequences are hierarchical. I am tired of debating somebody who cannot show inharent treeness but insist it is there. I will agree that one *can* implement start-up events as a hierarchy. But it is *not* the only way, and not the way I would choose. > > Why am I bother to explain this to someone who apparently doesn't even > grasp basic set theory (or at least whined about intimidation when I > challenged you)? > > But, once more, sets are fine when the data > is sequential or unordered... You just don't get it. It is not that they are "unordered", it is that they don't hard-wire in ONE-and-only-one order, because the "proper" viewpoint is relative to user needs rather than universal. Relational is the best known relativity tool out there. > -- > |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | -T- |