Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Thu Aug 04 2005 06:10 pm 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. > 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. >> 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"? > 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. In ALL cases, the tasks are distinct, not duplicates. >>>> 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. >> 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. Same with Trees. Fail to understand them at your cost, not your benefit. >> 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. >> 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? Where's your data normalization? Let me ask this: how do *you* define "relational database"?? >> 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. 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? >> 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! >> 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. >> 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. To be blunt, I think you're bluffing here. 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. 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. > 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*. >> 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? >>> 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. >> 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. > 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? >> 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. >>> 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. >> 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? >> >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? >> 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. 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. Note that the browser history tree and any logical tree structure of the pages themselves are **unrelated**. >> 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. > 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. >>>> 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. > Your argument here seems similar to the the DB index issue > here: the event engine my 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. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .