4 ms·
See to me the problem is the notion of tree structure itself. Forgive me because I don't know the correct mathematical way to talk about this: a tree is a parti
by neonnoodle 10y ago
See to me the problem is the notion of tree structure itself. Forgive me because I don't know the correct mathematical way to talk about this: a tree is a particular type of network in which nodes can have only one direct parent and thus only share siblings with the descendants of that single parent. What we are really lacking is a good network editor, which would encompass not only trees but also more complex rhizomatic network structures.
I think Ted Nelson's ZigZag structure is the closest anyone has come as yet, but manipulating those is NOT user friendly (to say the least). Visualization of multidimensional networks is difficult on many levels, particularly UI. At a certain point you probably come up against hard cognitive limits of human thought.
- chriswarbo 10y agoThe author does mention such networks (AKA "graphs"), and there's a lot of discussion in the article's comments. Whilst networks/graphs in general are very expressive, they can also be tricky to manage in some situations; e.g. think of a graph containing a cycle: A -> B ^ | | V D <- C How do we handle the order of these nodes and edges, e.g. for display or for serialising/deserialising? If we parse the graph from the text above, would we get an identical value to a parse of the following? B -> C ^ | | V A <- D If yes, would the user be upset that we've discarded the order? If no, then what is the form/structure of this extra information? Can it be represented as a specialisation/generalisation of a graph, or do we need something fundamentally different (a string, a parse tree, a partial-ordering, etc.)? If we forbid cycles, we get a "directed acyclic graph" (DAG); it's like a tree, but multiple parents are allowed. DAGs are nice since we can do things like topologically sort them. If we only allow nodes to have a single incoming edge, we get trees. The nice thing about trees is that they can be represented without any notion of "references" or "arrows". For example, we can write trees by nesting parentheses: (A (B C) D) is the tree: C <-- B <-- A --> D We can't write the following DAG just by using parentheses: should we put "C" inside the parentheses for "B", or for "A", or for both? C <-- B <-- A --> D ^ | | | \-----------/
- junke 10y agoWhat's wrong with (A (B C) C D) ? For circular structures, you could also have: '#1=(A . #1#) Which is: (A A A A A A A ....)
- chriswarbo 10y ago> What's wrong with (A (B C) C D) ? That's a different structure: it has two Cs in it. > For circular structures, you could also have: '#1=(A . #1#) That's what I meant by "references".
- junke 10y ago> That's a different structure: it has two Cs in it. It has two occurrences of the same C (but maybe I did not get your example).
- TuringTest 10y agoThere's a core abstraction lurking behind tools like ZigZag, the Leo editor, hashtags, and C pointers/linked structures. The hyperlink as the base abstraction allowed us to store and navigate individual nodes in a hypertext, but it doesn't work well for collections - thus it provides limited support for programmatic access. Conversely, pointers & references in programming languages allow for easy handling/transformation of large structures (either loops or recursive traversal), but there have never been a really good visual representation beyond a few nodes, and are difficult to navigate. A good tool should be based on an abstraction that worked well for linking information at separate places in the data space, and for retrieving collections as a whole. I have my ideas for how that abstraction should work, and even may develop a product around it eventually. ;-)
- _mhr_ 10y agoCan I email you? I'm working on similar ideas. I can't find an email address. My email address is in my profile.
- TuringTest 10y agoSure! I've just emailed you from my personal mail account.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- philsnow 10y ago> Conversely, pointers & references in programming languages allow for easy handling/transformation of large structures (either loops or recursive traversal), but there have never been a really good visual representation beyond a few nodes, and are difficult to navigate. Have you seen DDD (the Data Display Debugger) ? It's a graphical shell around gdb, and can help visualizing data structures.