Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Fri Jul 01 2005 03:30 pm topmind writes: >>> I have agreed that *people* naturally relate to trees. >> >> First, why do you think that is? > > That is a very good question that I cannot fully answer. Ask the chief > engineer(s) of the brain. [grin] They don't seem available for comment. We'll just have to guess. > I suspect in part it is because trees can be well-represented visually > such that the primary pattern is easy to discern. I say "primary" > because trees often visually over-emphasis one or few factors at the > expense of others. You make a lot of statements you don't support with examples. Can you provide an example of this happening? I think the reason is fairly simple. But I think we need to draw a distinction between representing DATA in a tree and representing some taxonomy as a tree. I (and others) have agreed that large taxonomies (unless the environment is very stable and clearcut) can be a problem. (I'm not sure that tables necessarily fix those problems, however, the problems come more from the difficulty of classifying things, IMO.) However, when it comes to representing certain *types* of datasets, I think that trees are the most appropriate form. Here we seem to be talking about tree-shaped *data*, each datum being a step in a larger task. It was entirely natural for you to break it down as an outline (aka tree) because that's exactly the shape of the data. People find this useful and natural for the simple reason that it allows you to focus on the level of detail desired at the moment. That's the whole point of an outline. File systems are hierachical for the same reason. It allows you to partition your data (files) into useful categories. It also allows you to perform operations on a sub-set easily without needing to access or filter the rest. Companies and the military are hierarchical for a similar reason: the "higher ups" deal with the big picture, the "low downs" deal with the details. > Sets can be used for visual inspection also, but it takes some training > and experience to get comfortable with them. Part of this is because > one must learn how to "query" sets from different perspectives. There > generally is no one right view (at least not on 2D displays) that > readily shows the pattern(s). One has to get comfortable with query > tools and techniques. Of course. Sets are raw, unstructured data. And reading raw data can fail to carry real meaning, hence the usefulness of charts and graphs. Very often, when dealing with a tabular dataset, I find myself quite surprised to see what the data is really saying once I start mining it with graphs and queries. >> Second, *people* create programs. Therefore, obviously, the tree must >> be one of the natural models. > > Do you mean natural to the human mind or natural to the universe such > that all intelligent space aliens will also dig them? Tree structures are a (universally) natural data type, so I do believe all intelligent minds will discover and use them. > Being natural does not necessarily mean "good". For example, it is > natural for humans to like the taste of sugar, fats, and fiber-free > starch. However, too much of these often make us unhealthy. Too much, yes. But without them, we perish. > Similarly, I agree that trees provide a kind of *instant gratification*. > It is the longer-term or up-scaling where they tend to bite back. Thus, > sets are for the more educated, enlightened mind in my opinion. I understand that's your opinion. It's unsubstantiated in mine. >> First, as I've already pointed out, cross-branch links don't make a >> tree not a tree. They just make it not certain types of trees. > > "Type of tree"? Please clarify. There are binary trees and n-ary trees. There are trees that are balanced and unbalanced. There are trees that require all nodes to be unique and trees that allow nodes to be repeated. There are trees that allow nodes to reference each other (consider links in a Unix filesystem). There are trees where the branches are allowed to reconnect. A tree is really any structure with a "root" and child nodes. > If you print out the code on a big sheet of paper and draw the lines > between the subroutine references, you will see that it is *not* a > tree. In most programs of my experience (30 years, dozens of languages), there is a fairly strong tree shape to the relationship between functions. You have your root--the code entry point--and a set of nodes that, in a well-written program--tend to proceed from high level nodes to low level nodes. A fellow I used to work with wrote a program that, given the source files for any C program CREATED the tree of routines and calls. The only thing you really have to be aware of is recursion, and that pretty much just requires not repeating an existing node (or in some call graphs I've seen, repeating it only once as a leaf). > Now, *any* graph can indeed be represented as a tree if you are willing > to display inter-branch references as duplicate nodes, which is what > the multiple subroutine calls essentially are. Or (as this fellow did) as branches that refer back to existing nodes. And consider this: the call path of a program executing (in a single thread environment) is 100% tree-shaped (with recursion caveat). That is, if you graphed it from start to finish, you'd end up with a huge, perfect tree. And, yes, some nodes might be repeated, but that doesn't make it not a perfect tree (by perfect I mean no nodes cross-link). The parse tree created by a parser repeats nodes--for example, in most parse trees, there are probably a LOT of "if/else" nodes. >> Second, you don't really algorithm, you mean program. Algorithms >> typically ARE very hierarchal ever since structured programming was >> invented. Smaller blocks within larger blocks, just about every >> algorithm is structured that way. > > On a small scale, yes. On a bigger scale it is not hierarchical, per > above. Many programs are generally hundreds of small trees joined by > lots of references that bust tree-ness. Well-written programs ARE usually tree-ish in my experience. High level routines call low level routines. I'm sure you've heard the terms "top down" and "bottom up". These refer to the tree-ish-ness of program analysis and design. > Picture drawing hundreds of small trees randomly scattered on a large > piece of paper. Now randomly draw thousands of lines between various > nodes of the different trees.... But it's NOT random. Low level routines don't call high level routines. >> You can label them a "lie" if you like, but they appear to reflect the >> truth of very many situations to me. > > Well, every abstraction is probably a lie to some extent. The term "lie" is pejorative and, I think, misleading. A lie is told with the *intent* to deceive. Abstractions are told with the intent to get at a truth. If you really feel tree-shaped abstractions are incorrect, a better term might be, well, "incorrect". (-: >> Clearly most of the human race would seem to agree, since you admit >> that "most people would naturally produce a tree." > > Because most people are naive and go with instant gratification and/or > the comfortable. Sets are admittedly not immediately comfortable, but > they allow one to shift up a level of complexity and change management. > Enlightenment comes with a price. That's life. Hmmm, the "everyone else is dumb but me" line is so often the mark of a kook that I recommend you be careful about it. And, for my money, you're just plain wrong. Sets are raw, unstructured data. You've agreed that making sense of them requires tools that add, or highlight, structure. That's exactly what hierarchies do. One could just as easily claim that enlightenment involves embracing all forms of tools that allow you to mine datasets for their value. One might also argue that the naivete is in failing to recognize the value of higher data structures. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .