Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Chris Sonnack on 4 Aug 2005 18:10 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]") >>>> <load loop> >>>> 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 <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 6 Aug 2005 04:40 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]") > >>>> <load loop> > >>>> 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 <Chris(a)Sonnack.com> _____________| How's my programming? | > -T-
From: Chris Sonnack on 8 Aug 2005 19:58 topmind writes: >> They're still tree-like, >> They're still very hierarchical. > > "Semi", maybe. "Very", no. We've been going around this mulberry bush too long, and I'm sick of it. Let's just assume the next posts will all be a variation of "yes it is", "no it isn't" and agree to disagree. I find breaking a task down into outline form productive, obviously a lot of people do, you don't, end of story. >> 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". The brain is much more than its interconnections. The brain ALSO has the mechanism that makes it active--specifically the chemistry of the synapses. In a sense, the brain is like a class: it has the data and code that operates on that data. >> 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. Do you think fuzzy logic is implemented without binary? Regardless, some problems--and I had a couple specific ones in mind when I wrote the above--are/were only solvable by grokking the 1s and 0s. > 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). Multi-state logic is built on binary logic. Learn basic information theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it. >> Fail to understand [trees] at your cost, not your benefit. > > Same with sets. Absolutely. (Are you implicitly agreeing trees are as important as sets to a well-rounded programmer?) >>>> 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. (This, as stated, is *absolutely* incorrect, BTW.) >> ?!?! 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. You could, although I'm not sure you'd end up with a purely relational database that way (I'll have to think about that one). I am pretty sure it would only work under very specific data requirements. Regardless, in the case I had in mind, it wasn't. The question remains: given a flat-table (non-relational) database, can you still write an SQL query. Answer: of course you can. SQL is JUST a query language. >> Where's your data normalization? > > I am not sure normalization is a requirement for "relational". For the pure (mathematical) definition, I'm pretty sure it's one of the central, defining features! http://en.wikipedia.org/wiki/Database_normalization (Interesting reading, that. I hadn't realized there was a fifth and sixth normal form.) > 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". Empty cells? Where did that come from? Are you talking about NULL fields? Row duplication?? What??? >> 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. 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. >> No, it's a data storage concept. There are many reasons why the >> physical storage location might change. > > Huh? Please clarify. Migration, rollups, new systems, OS changes, format changes, etc., etc. >> 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. Exactly as any record is uniquely indexed by its key(s). > If you yank or change a segment in the path, you bust an existing "key". Yep. > And if there was no difference, then why not go with sets? File systems have more flexibility than databases. Consider this: what happens when several of my files *ARE* databases. Big ones. 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. >> 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. The UK was "BobsProject". Bob left. Someone changed the UK, but I don't know the new one. In a normal filesystem I could poke around in the general area where project files were stored and very likely find it (I know this, because I've done it). With a database, you can only hope there's an attribute still attached that might turn it up in a query. Maybe so, maybe not. Maybe when Fred took over, he changed the attributes just slightly due to his own personal preferences. >>> "Locations" are increasingly obsolete and meaningless in cyberspace. >> >> [The] bits still need a home *somewhere*. > > The "real world" is not tree-shaped for the most part. Mu. >> 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? Nope, since it really wasn't a structure question. Your inability to answer a simple set theory question indicates you don't know set theory. That's fine. Just checking. End of story. >> 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. Jets in they sky don't have a relationship. Bosses and employees do. Hierarchies *are* about relationships, and like it or not, the world is *filled* with them. >> 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? Let's recap. You claimed GUI software--note the term: SOFTWARE--was not hierarchical. I showed you that it was. Then you shifted to talking about GUI usage. Software--in general--is hierarchically structured. It has high-level routines, mid-level routines and low-level routines. >>> 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. Once more: >You> But a pure tree has no duplicate nodes. >Me> Show me one authority that agrees. I don't know how to make the question plainer. >> 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. You'd lose that paycheck. Consider the "list" of routines visited during the execution of a program. It represents the thread of execution. It is a DYNAMIC thing generated by a running program. If that thread of execution re-visits a routine more than once, then that routine MUST appear in the list more than once. THAT IS THE REALITY--the program re-entered that routine. If you treat the "main" function that started the program as the root, you can draw a tree that represents that list of routines. That tree is "perfect" in the sense that no node "cross-connects" to any other node. Yes, it does have "duplicate" nodes, but NO that doesn't bust "treeness" (no matter how much you might wish it did). It is a "perfect" tree that represents the thread of execution of the program. > I am only defining "pure tree" as one without duplication. Your definition is seriously broken. Find one authority that agrees. > Are you suggesting that since reality has duplication that our > databases should also even if there are techniques to remove it? But they don't *remove* it, they (in a sense) compress it by normalizing the data. In a database version of the call graph, you'd have one record for each routine and a separate--"duplicate"--record in some other table for each time you visited that routine. (In fact, given the appropriate query, the duplication "returns".) >>>> ...the parse tree itself is still a "pure" tree, >>>> because each "IF/ELSE" is contextually different. >>> >>> ...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? Not at all, but it has nothing to do with parse trees. > If not, then please apoligize for insulting me. It still looks like you don't know what a parse tree is, so no. >> 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). I have been *talking* about the app developer all along. I have not been talking about implementing the GUI engine. The code I showed you was developed (by me) as an APPLICATION. As I said last time: >> 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? I **showed** it to you several posts ago. That was APPLICATION code. > Remember, I am NOT asking how one may impliment the event manager. > We are using the tool, not making it here. And I have responded ALL ALONG as an app developer. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 9 Aug 2005 01:42 I am splitting my replies into 2 or more sections because this thread has grown too big. Chris Sonnack wrote: > topmind writes: > > >> They're still tree-like, > >> They're still very hierarchical. > > > > "Semi", maybe. "Very", no. > > We've been going around this mulberry bush too long, and I'm sick of it. > Let's just assume the next posts will all be a variation of "yes it > is", "no it isn't" and agree to disagree. I find breaking a task down > into outline form productive, obviously a lot of people do, you don't, > end of story. I also use "mental trees" when breaking down tasks for analysis, but it is highly draft-mode. When it comes to actual implementation, one factors and rerranges such that the treeness shrinks as it grows into production. > > > >> 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". > > The brain is much more than its interconnections. The brain ALSO has > the mechanism that makes it active--specifically the chemistry of the > synapses. In a sense, the brain is like a class: it has the data and > code that operates on that data. I suppose any paradigm can model a general brain. I don't see anything about it that is inherently OO over others. One can just as easily, perhaps more easily, view it as a many-to-many table of weighting factors. > > > >> 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. > > Do you think fuzzy logic is implemented without binary? Our computers currently use binary, but 3-ary and 4-ary modles are certainly possible and some quantum theorists suspect that future chips may use multiple states instead of just 2. They are interchangable; each can emulate the other. > > Regardless, some problems--and I had a couple specific ones in mind when > I wrote the above--are/were only solvable by grokking the 1s and 0s. Only? I suppose every dog has its day. > > > 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). > > Multi-state logic is built on binary logic. Learn basic information > theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it. > Learn about Turing-Complete, emulation, and substitutability. They can be built on n-ary state systems and they are all interchangable. Today's hardware is not necessarily tomorrow's. I lot of production RDBMS use 3-value logic because of those damned Null's, I would note. (Personally, I would like to see Null tossed or reduced.) > > >> Fail to understand [trees] at your cost, not your benefit. > > > > Same with sets. > > Absolutely. (Are you implicitly agreeing trees are as important as > sets to a well-rounded programmer?) Yes. Trees for the small and demos, sets for real projects. > > > >>>> 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. > > (This, as stated, is *absolutely* incorrect, BTW.) Prove it. Relational does NOT need multiple tables. "Relational" does NOT mean "linking". Look it up. > > >> ?!?! 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. > > You could, although I'm not sure you'd end up with a purely relational > database that way (I'll have to think about that one). I am pretty > sure it would only work under very specific data requirements. > > Regardless, in the case I had in mind, it wasn't. The question remains: > given a flat-table (non-relational) database, can you still write an > SQL query. Answer: of course you can. SQL is JUST a query language. What exactly is a "flat" table? > > >> Where's your data normalization? > > > > I am not sure normalization is a requirement for "relational". > > For the pure (mathematical) definition, I'm pretty sure it's one of > the central, defining features! > > http://en.wikipedia.org/wiki/Database_normalization I dispute that. Poorly-factored Boolean algebra is *still* Boolean algebra, for example. > > (Interesting reading, that. I hadn't realized there was a fifth and > sixth normal form.) They are often not very practical, and in some cases seem to increase redundancy. > > > 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". > > Empty cells? Where did that come from? Are you talking about NULL > fields? Row duplication?? What??? This is getting into a long, drawn out debate about the nature of relational. Here is something related: http://www.c2.com/cgi/wiki?TupleDefinitionDiscussion > > >> 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. > > 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." > > > >> No, it's a data storage concept. There are many reasons why the > >> physical storage location might change. > > > > Huh? Please clarify. > > Migration, rollups, new systems, OS changes, format changes, etc., etc. Yes, but ideally we abstract away from those. For example, we may create an ODBC name for a database reference. Even if the machine is moved, that same name can still point to the same one. (In the real world sometimes things need to be split for performance or jurisdiction reasons. But this is true of everything.) > > >> 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. > > Exactly as any record is uniquely indexed by its key(s). But keys are fragile. That is why it is often best to have "dumb" keys that don't carry any meaning. > > > If you yank or change a segment in the path, you bust an existing "key". > > Yep. > > > And if there was no difference, then why not go with sets? > > File systems have more flexibility than databases. Fooey! You already agreed that paths were fragile, being hard-to-change. > > Consider this: what happens when several of my files *ARE* databases. > Big ones. I am not sure what you are getting at. That is a DB implementation detail. A DB can be implemented with Tinkertoys (Harvard project?) if one wants to wait long enuf for the results. http://www.cob.sfasu.edu/sbradley/tinkertoy.html > > 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. I see no reason why a relational system cannot have the same kind of thing. However, usually you will find that security is not hierarchical as it scales. This is why we have things such as Access Control Lists, which are essentially many-to-many tables. > > >> 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. > > The UK was "BobsProject". Bob left. Someone changed the UK, but I don't > know the new one. In a normal filesystem I could poke around in the > general area where project files were stored and very likely find it > (I know this, because I've done it). > > With a database, you can only hope there's an attribute still attached > that might turn it up in a query. Maybe so, maybe not. Maybe when > Fred took over, he changed the attributes just slightly due to his own > personal preferences. Just because you are not adept at non-tree searches does not mean the rest of us are also not. I have lost stuff in trees many times. The solution was to do non-tree searches (start-to-end) to hunt for attributes. A relational system would make it easier to put meta-data tags on something with less worrying about other tags or whether our classification approach is on the "right track". Sets also have "near", it is just a multi-dimensional "near". Trees are stuck in 2D. [end of part 1] -T-
From: Dmitry A. Kazakov on 9 Aug 2005 12:00
[Nothing to do with polymorphism, but...] On Mon, 08 Aug 2005 18:58:01 -0500, Chris Sonnack wrote: >> I don't know if "necessary" is the case, because there are things such >> as fuzzy logic. > > Do you think fuzzy logic is implemented without binary? Implemented is a wrong word here. Logic isn't implemented. Fuzzy logic is a continuation of the crisp logic. But it has sufficiently different properties. For example, the law of excluded middle is wrong in fuzzy logic: A V~A does not hold. > Regardless, some problems--and I had a couple specific ones in mind when > I wrote the above--are/were only solvable by grokking the 1s and 0s. Important question is whether the number of 1s and 0s is finite. To make a jump to fuzzy logic you'll need continuum. And that is much more than the set of integer numbers. >> 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). > > Multi-state logic is built on binary logic. Learn basic information > theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it. No, this is wrong. The propositions of a multi-state, fuzzy or intuitionistic logics aren't ones of the crisp logic. Though it is possible to build some meta system based on crisp logic to analyse the propositions of the "object" [non-crisp] logic. Probably this what you meant. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |