Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Mon Aug 08 2005 07:58 pm 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 _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .