Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : topmind Date : Sat Aug 06 2005 02:40 am Chris Sonnack wrote: > Once more into the breach... > > topmind writes: > > >> Trees--as an analytic tool--are *extremely* valuable, and for good > >> reason. You demonstrated this yourself when you described a task as > >> an outline. And, contrary to your statements about size, they become > >> even more valuable when the task is large. > > > > But they are no longer (pure) trees when the task gets large. Tree-ish, > > or semi-tree if you will, but not pure trees. > > 1. Actually they *are* "pure" trees. (see below) > 2. Even if they weren't, so what? > They're still tree-like, > They're still very hierarchical. "Semi", maybe. "Very", no. I will agree that many things have a degree of "tree-ness" to them. However, I have not seen decent ways that OO and other tree-tending techniques can deal well with imperfectness of such semi-trees. Dealing with all the exceptions by bending and twisting tree tools is a bigger mess than just using sets. One you learn how to navigate sets, they are not the buggaboo you guys make them out. > > > Further, there may be other non-tree ways to specify algorithms, > > it is just that there is not a lot of research on that. > > Wishful thinking. I submit that humans have been breaking down large > tasks into smaller ones a very long time. The outline (aka tree) is > the result of experience. If a better way existed, I think we'd have > some sense of it by now. Like I keep saying, they are only trees on a small scale. If you look at the big picture and fill in the details, the tree-ness score goes down. > > >> Nowhere above am I talking about code. I'm talking about > >> breaking down a large project into separate tasks. Exactly what you > >> did a few weeks ago with a very small task. [...] > >> > >> I would submit that an outline (aka tree) is the ONLY viable way to > >> do such a breakdown. It's not a "convenient lie", it's a reality. > >> Large tasks are made of small tasks. It's natural. > > > > Are you talking about software design, or Gantt-charts and the like? > > Or even, "how do we build a house"? Houses are built hierarchically? Howdya recon? Tree house? :-) > > > Besides, for non-trivial projects there is often repetition of some > > tasks such that it is not a pure tree. For example, multiple tasks on > > different branches might have a "make photocopies" sub-task(s). > > Those are NOT duplicate nodes. You are copying different pages for > different purposes. Or even the same pages for different purposes or > at a later date. They are duplicate nodes with non-duplicate "parameters". Further, there are likely shared copies of the documentation in such projects. There will likely be a lot of "See also" references in them (if they are any good). The see-also patterns of documents is usually NOT a tree. > > In ALL cases, the tasks are distinct, not duplicates. Only if you ignore detail that hurts your argument. > > > >>>> Nope. Records are dumb. They have no interface. > >>> > >>> They have no "interface"? Data queries. > >> > >> Records can't be queried. DATABASES can. Records are just dumb > >> "things"....a collection of fields. > > > > So are classes until one "runs" the software. I don't see what > > you are getting at. > > Obviously. Classes have code+data. They are "active" or "intelligent". > Records are just data. No code, no activeness, no intelligence. The brain is merely a bunch of "weighting factors" between nodes and links where there does not happen to be signals running through a given part of it. The brain must be a piece of junk then, eh? The brian is mostly "just data". I don't claim that data is self-standing. The relationship between data and behavior is a kind of ying-yang relationship. > > > >> All programmers ultimately do use 1s and 0s. We just have tools that > >> usually shield us from the messy details. More to the point, what the > >> DB indexes demonstrate is that, yet again, hierarchical organization > >> can be a huge win. > > > > It does not demonstrate anything more than 1's and 0's do. You have not > > effectively argued why trees are immunite from the binary digit analogy > > here,... > > If your "binary digit analogy" is supposed to illustrate that programmers > don't need to be concerned with 1s and 0s, it's incorrect. Programmers > very definately benefit from understanding the 1s and 0s. In some cases, > it's *necessary* to solve or understand a problem. I don't know if "necessary" is the case, because there are things such as fuzzy logic. However, we still use boolean algebra for boolean expressions I have to agree. But still this is because we find boolean alg useful, NOT because our chips may be based on it. (4-state chips are under research, I would note). > > Same with Trees. Fail to understand them at your cost, not your benefit. > Same with sets. > > >> So you use multiple partition schemes where needed. No biggie. > >> The fact remains, without partitioning *somehow*, you have a mess. > > > > RDBMS partition information into tables, records, and columns. > > And your thesis is that, while life is NOT tree-shaped, it IS shaped like > tables, records and columns? > > I can't speak for you, but I see a lot more hierarchy in my life than I > do charts and grids. Most things in *my* life are NOT rectangular. > Think how you want, but I find sets and tables better for myself. I used to think more tree-ish, but grew up. > > >> I thought you were a "database guy"? Think about a database with only > >> one table. Think you can write an SQL query to return a subset of > >> the records in that table? Of COURSE you can. > > > > If it has one table, it is still relational. > > ?!?! Are you quite sure about that? > > What do the fields relate to? > Where's your FKs and relationships? > Where's your one-to-many or many-to-many? All these can be done with a single table. For example, a "parentID" reference can be a foreign key to the same table. > Where's your data normalization? I am not sure normalization is a requirement for "relational". However, there are different ways to interpret "duplication" for empty cells. Empty cells do not have to take up physical space, especially in "dynamic relational". > > Let me ask this: how do *you* define "relational database"?? > Note that "relational" does not mean cross-references between multiple tables, contrary to popular belief. "Relational" actually is a mathematical term for "table". The term does NOT mean inter-connected. > > >> Of course, and your page mentions that. I was commenting there on > >> the stupidity of subjecting human users to numerical identifiers. > > > > Well, I shall refer you to a long debate on this topic: > > > > http://www.c2.com/cgi/wiki?AutoKeysVersusDomainKeys > > http://www.c2.com/cgi/wiki?AutoKeysVersusDomainKeysDiscussion > > > > It is mostly moot to this debate anyhow, as described later. > > > > By the way, what would you recommend the US government use > > instead of Social Security Numbers to track people? > > How many **other** people do you refer to by their SSN? It's one thing > to know your own BA number....quite another to know others. I'd bet > most people don't even know--by memory--ANY other SSN than their own. Depends on the context. A data-entry operator will generally not want to find records to change using just a name. > > Think about it. What world would you prefer? One where you know folks > by their name, or one where you know them as 123-45-6789? It depends heavily on whether I am dealing with a handfull of people or jillions. Names are fine at the few-hundred level. > > > >> I looked at your--whatchamacallit--finder window. Considering that > >> in a day's work I reference hundreds of files, having to use some > >> GUI search tool each time I wanted to locate a file.....NFW. > > > > You can create your own short-cut references, I would note. I do this > > in Windows Explorer (with trees) because I hate path clicking. > > HUNDREDS of shortcuts? No thanks! Put your shortcuts into your own personal tree. It works fairly well for a few hundred. > > > >> What makes you think a dumb key prevents files from being moved? > > > > Because there is *no reason* to change them if they are > > indeed "dumb". (BTW, what do you mean by being "moved"? > > That is a tree concept, not a relational one. See below.) > > No, it's a data storage concept. There are many reasons why the physical > storage location might change. Huh? Please clarify. > > >> You seem to be assuming that files in your system never move. I > >> have no reason--quite the contrary, in fact--to think that's true. > >> Files move for lots of reasons. > > > > In relational theory you generally don't "move" the node, but simply > > move/change references or attribs. > > You throw around terms, like "relational theory", pretty casually for > someone who doesn't even seem to know what a relational database is. No, it appears you don't. > To be blunt, I think you're bluffing here. Oh really? > > Quote C&V from the "theory" or I'll just believe you are making it all up. > > Let me see if I can make this as simple as possible..... there's really > NO difference between having a file in "BobsProject" directory verses > it having a "BobsProject" attribute in a database. Yes there is. Tree leafs are uniquely indexed by their path. If you yank or change a segment in the path, you bust an existing "key". And if there was no difference, then why not go with sets? > > If "BobsProject" becomes obsolete and leaves the system, I'll still fail > to find the directory or file. With a browser, at least I can poke > around to see if I find something helpful. With search dialog, I'm > left tryingt to think of other search parameters. I am not sure what you mean here. > > > You are appearently thinking in terms of physical 3D boxes. Trenscend > > that. Cyberspace lets us. "Locations" are increasingly obsolete and > > meaningless in cyberspace. > > When you're done worshipping your crystal and have returned to the real > world, we'll explain how bits still need a home *somewhere*. The "real world" is not tree-shaped for the most part. > > >> What you don't seem to understand is that a regular hierarchical file > >> system is logically equivalent to your system. You have attributes, > >> a regular FS has path parts. If you change the attributes/path parts, > >> the file "moves" and people's static references to it are no longer > >> valid. > > > > An attribute shouldn't disappear unless it is no longer valid. > > If your reference to it is based on that disappearing factor, then > > it is *proper* for the DB to no longer return it. It is doing its > > job right by giving you exactly what you ask for. > > # A FOLDER shouldn't disappear unless it is no longer valid. > # If your reference to it is based on that disappearing FOLDER, then > # it is *proper* for the FILESYSTEM to no longer return it. It is > # doing its job right by giving you exactly what you ask for. > > So.... what's the difference? Trees are heavily dependent on paths. It is a "weakest link in the chain" kind of thing. With orthogonal attributes the loss of one attribute generally won't affect usage of others because they are not chained together. Paths thru the tree are chains. The only queries that will return a different answer are those that reference the changed attribute, which is how it SHOULD be. However, a tree paths forces you to use a bunch of attributes to identify something regardless of whether your location activities really depend on those attributes. Example: c:/friends/lawyer/bob.txt If Bob becomes your enemy or changes career, this path is either lying or will not return bob.txt anymore. A given query to Bob will only return a different answer if it is based on friendliness or career. (Plus, we can add a history table without busting existing info.) > > > >>> For example, Bill Gates may be "superior" from a money tally > >>> standpoint, but if he ends up in hell when he dies (as a > >>> hypothetical example), then he is not superior from a > >>> religious standpoint. > >> > >> Why do you think an attribute applies to all contexts? > > > > Ahah! So you admit there is no One Right Level/View/Taxonomy. > > So, why should file systems be any different? > > Specifically with a file system, because there IS a strong context. > > With other situations where trees are useful, because there is a > primary context. No. Context importance is relative and changes. > > > >> Let's talk set theory. You're big on sets, hopefully > >> you have some grasp of the underlying theory of sets. Let's find > >> out. > >> > >> Here's a set: {{red} {blue} {green} {yellow} {thursday} {28} {}} > >> > >> What does it mean? What is it's structure? > >> > >> Here's another: {{1} {3} {2} {1.5} {34} {99} {0}} > >> > >> What does it mean? Is it the same as the other set? If so, why? > >> If not, why not? > >> > >> Here's another: {{} {} {} {} {} {} {}} > >> And another: {{{}}} > >> > >> Are these the same or different from the first two? Why or why not? > > > > I didn't propose a definition of "structure", so I don't > > see the point in this exercise. > > To see if you have even a *clue* about sets. You glibbly wave the term > around a lot and make extravagant claims about their superiority, but > it's becoming increasingly questionable whether you actually understand > them. Well, if I am that misinformed, I have no way to tell at this point. "Structure" is just not a mathematically-precise term. If it is, I am unaware of the definition. > > > Let's explore some more realistic scenarios instead of Foo Bar examples, > > how about? > > If you can't answer trivially simple questions about trivial examples, > what's the point in discussing more complex ones? If you can demonstrate that "structure" is a mathematically precise term, I will lend credence to your claim of my delusionment. Deal? Again, I request we use something besides foo-bar examples for this. > > > >> What happened when each of the three bosses asked you to be at a > >> different meeting scheduled for the same time? > > > > I would tell them there was a conflict and suggest they > > consult one another to find an agreeable solution. > > So, you bumped the issue up to a higher level and let them work out > which of THEM had a higher priority for your time. In other words, > it was *entirely* hierarchical. > > Which was exactly my point. Being "higher" is not necessarily hierarchical. Jet "A" may be higher than Jet "B" in the sky, but that does not necessarily imply that the placement of jets is hierarchical, for example. Picture a graph (network) on a cartesian grid. Some nodes are going to be higher valued in a given axis than others. > > > >>> No, that is not a pure tree. > >> > >> You keep saying that like it means something. It doesn't. > > > > I don't know of any formal metric for tree-ness of imperfect trees > > at this time,... > > Not surprising, since you don't seem to actually know much about them. > Then where is your grand tree-ness metric algorithm? Criticism is easy. Providing alternatives is the stumper. > > >> The browsing *history* follows a recursive path. The browser software > >> does not. Your claim that GUI software is recursive is incorrect. > >> > >> GUI **usage** may recurse, but so what? > > > > Recursion busts trees. > > 1. No, not really. > 2. So? Who really cares what shape someone's **usage** pattern is? > > You DO understand the difference between *using* a browser and writing > the code for it, don't you? > To keep things clear, let's stick to one viewpoint or the other. You pick. Then, let's revisit the topic. Deal? > > >> >you> But a pure tree has no duplicate nodes. > >> > >> >me> That's BS. Show me one authority that agrees. > >> > >> Your turn again. > > > > Sigh, we are back to this again. > > Sigh, and you STILL got it wrong. > > > You know, it is tough to describe this very well with words. > > For the fourth or fifth time: I UNDERSTAND THE PICTURE! > Do you understand the question? No. > > > >> What part of "that IS the reality" don't you get? If a routine is > >> entered multiple times, the call graph **MUST** have duplicates. > >> (You DO know what a call graph is, don't you?--a(n imaginary) tree > >> listing the thread of execution of a running program.) > >> > >> Once more: the call graph is a "pure" tree--no node links back, no > >> branches connect--but does indeed have "duplicate" nodes. That is, > >> the name of the node is duplicated. In the reality of the running > >> program, each visit to a given routine is *contextually* different. > > > > No, it has some parts that are the same (same routine called) > > and some parts that are different (time stamp and params). > > If you break the node into full granularity... > > "full granularity"? :-) > > Nevertheless I can parse what you're trying to say. And you're wrong. > Just because multiple node happen to *refer* to the same thing, the > nodes themselves--their place in the tree--ARE NOT DUPLICATES. They > represent distinct, *necessary* (we presume) occurrances. They *are* duplicates or pointers (cross-branch). As proof, if we want to change the name of or address in RAM of the called routine, we have to update multiple spots. It is a fricken graph. I would bet a paycheck on it if my wife would let me. They are multiple references to the same thing and they bust tree-ness. > > Put it another way. Go back to that browser usage example where you > "re-enter" the same page multiple times. The tree that reflects your > browsing path WILL HAVE DUPLICATE NODES, and those duplications > represent reality, because you did visit those pages multiple times. So? I never said that reality didn't have duplication. I am only defining "pure tree" as one without duplication. Are you suggesting that since reality has duplication that our databases should also even if there are techniques to remove it? I would just rather switch to sets than live with a bunch of duplication. > > Note that the browser history tree and any logical tree structure > of the pages themselves are **unrelated**. See above about re-starting this section of the conversation. > > >> Consider a parse tree. Most programs use the language statements many > >> times, so there are duplicate, say, "IF/ELSE" nodes. Probably lots > >> and lots of them. But the parse tree itself is still a "pure" tree, > >> because each "IF/ELSE" is contextually different. > >> > >> Get it? Keep at it until you do. > > > > I think the problem is that the granularity of your nodes is too large. > > That has nothing to do with it. The problem is that you apparently > REALLY don't fully understand the concepts involved. Frankly, I think the problem is you, not me. You see "almost" treeness and interpret that to mean pure treeness. > > > Generally I ignore the IF/ELSE issue here, but would like to point out > > that in some languages control constructs such as IF and WHILE are > > simply function calls with some fancy scope management features > > used rather than being built into the language. > > 1. That doesn't change a thing with regard to parse trees. > 2. That is USUALLY the case unless you're programming in assembly. > (That is, If/else and while are high-level constructs implemented > by the language--they ALL translate to something more complex > than the words "if" and "While".) > > We can apparently add parse trees to the list of things you don't > really understand. In languages such as SmallTalk, LISP, and TCL, one can roll-their-own control structures using the language itself. Do you question this? If not, then please apoligize for insulting me. > > > >>>> Main > >>>> Initialize_Common_Globals() > >>>> Initialize_Program() > >>>> Load_Program() > >>>> LoadProperties() > >>>> Get_Special_Target_List() > >>>> LoadList(SpecialTargetList) > >>>> OpenTable("[SpecialTargets]") > >>>> > >>>> Close > >>>> Load(ApplicationForm) > >>>> > >>>> Et cetera. Get the picture? > >>> > >>> That looks like an implementation of the event-handling engine, > >>> not actual events themselves. > >> > >> What part of "my programs definately have high level routines and > >> low level routines" did you fail to apprehend? > > > > Remember the context is event-driven programs, not all programs. > > So? The point was that this GUI program definitely has higher and > lower level functions. Apparently you no longer disagree. It *can* be implemented that way under the hood, but the implementation is moot to the user (app developer). > > > Your argument here seems similar to the the DB index issue > > here: the event engine [may] use trees underneath. > > No, you're so far off course I don't even begin to know how to answer > that. > > > ... but the app developer doesn't give a flying flip if it is built > > with a hidden tree or gerbiles underneath. > > This isn't about anything hidden or under the hood. > It's about how you write a program. > It's about how you analyse a problem and break it down. Where is the "tree" in an event-driven application? Remember, I am NOT asking how one may impliment the event manager. We are using the tool, not making it here. > > > > -- > |_ CJSonnack _____________| How's my programming? | > -T- .