5 ms·

We do not have a general purpose tree editor because trees are quite the complicated structure, and most valuable operations on trees require quite a bit of kno

by hibikir 13y ago

We do not have a general purpose tree editor because trees are quite the complicated structure, and most valuable operations on trees require quite a bit of knowledge of what the tree represents. Look at, for instance, source code. In many languages, we represent code in a tree-like structure, just with text and braces/parenthesis/tabs as indentations. But we all know that there are major limitations on how to represent a class. If you have 200 methods in a class, said class is unwieldy. If your methods are very deep, the whole thing also becomes unwieldy, so we make them smaller. We'd still do that with huge monitors that could show lots and lots of code at once: Without abstraction, any nested structure is hard to manage. Many text editors will collapse levels for you, but really, how often do you all use them? Whenever you need to use them, it's a smell, because it means that the structure is getting too complex for a mind to handle. This is not an issue that is unique to code. Any tree structure has the same issue of abstraction: We are not designed to handle more than one layer at a time, unless we are dealing with a tiny number of nodes. We have trouble seeing trees and navigating trees, so of course we can't have good general tree editors. I've seen four attempts at just general tree visualizers at work in the last year. The most successful barely pay lip service to regular tree 'views', and instead try to answer secondary questions that would help us know how we want to explore the tree. And, as others here have already said, there's always non graphical representations. find, awk and grep can go very far when you are trying to find things on a tree. Proper indexing does a good job too.

seanmcdirmid 13y ago
> Many text editors will collapse levels for you, but really, how often do you all use them? Whenever you need to use them, it's a smell, because it means that the structure is getting too complex for a mind to handle. I agree with you on everything except this: code folding is very useful in creating a high level view of code to reason about. I would argue further for code bubbles, but they haven't really been done right yet; perhaps we will eventually see some interesting good solutions in LightTable.
- kristiandupont 13y ago
  Agreed. I frequently mention Code Browser (http://tibleiz.net/code-browser/ http://tibleiz.net/code-browser/) which has multi-level folding that works very well. When I work solo on a project, I tend to fold many levels deep and create what would otherwise be a "smell" but it doesn't seem to cause problems. Unfortunately, I can't use it when working with a team because I know of literally nobody else who uses the editor. I've considered writing a plugin for LightTable or perhaps Sublime Text but I have no experience with either of their API's and I am not sure whether it would even be possible.
capkutay 13y ago
"We do not have a general purpose tree editor because trees are quite the complicated structure, and most valuable operations on trees require quite a bit of knowledge of what the tree represents." Definitely...Also, trees are pretty abstract data structures. You can imagine a min-heap as a tree but for practical purposes you can also think of it as an array where there are special rules for interacting with elements (adding, removing, finding the child of a node, etc). It could be a pain to try to generalize something so abstract and with so much room for complexity by making a tree editor... It's the same reason why UI's for software development haven't taken off. When something is that abstract and complicated, it's almost harder interacting with an interface that tries to 'dumb it down'. Not to mention the lack of control such interfaces would introduce.
- JadeNB 13y ago
  > Also, trees are pretty abstract data structures. You can imagine a min-heap as a tree but for practical purposes you can also think of it as an array where there are special rules for interacting with elements (adding, removing, finding the child of a node, etc). This seems to be a bit of a red herring: you can think of an array as a contiguous region of bare bits in memory where there are special rules for interacting with elements—and similarly for any data structure—but that point of view doesn't seem to be the most useful (except possibly, in the array case, for programming in C).
gcb0 13y ago
i don't agree. there are several representations for tree->text... but the tree itself are pretty much limited. cyclical, not cyclical. root node or loose. for an editor you probably don't even have to worry about the rest such as direction of traversal etc.
arethuza 13y ago
"We do not have a general purpose tree editor because trees are quite the complicated structure" Exactly - my response was basically - "We don't have a general purpose tree editor because we don't have general purpose trees".
agumonkey 13y ago
Opinionated lisp ~noob here. I tend to see sexps as a general tree and emacs+paredit[1] as a general tree editor, and even though I completely agree about your point on 'if you need folding maybe your design is wrong hence no need for tree structures'. I really feel limited whenever I use a non sexp based language. It's like having you're own little private refactorer at your fingertips. And even for small code it's a noted pleasure. [1] emacs or whatever program you use, as long as it give you tree walking keybindings.
jalanb 13y ago
"We are not designed to handle more than one layer at a time" anymore than we are "designed" to handle any source code format, surely?
adriano_f 13y ago
Lots of interesting points, but I disagree with the logic that "we are not designed to handle more than one layer at a time" necessarily implies that a tree-editor is impossible/undesirable. Yes, we are only built to think of an idea/code/story/essay at one "level" at a time. You are either thinking about the overall structure of the code, or a particular line. A particular scene, or the overall plot. But that's precisely why a tree editor, one that separates the levels for you, is so useful. You can always "zoom in" to the details by going right, and "zoom out" to the big picture by going left. Have a look at Gingko, for our approach to solving this problem: http://gingkoapp.com http://gingkoapp.com

by hibikir 13y ago

seanmcdirmid 13y ago

> Many text editors will collapse levels for you, but really, how often do you all use them? Whenever you need to use them, it's a smell, because it means that the structure is getting too complex for a mind to handle. I agree with you on everything except this: code folding is very useful in creating a high level view of code to reason about. I would argue further for code bubbles, but they haven't really been done right yet; perhaps we will eventually see some interesting good solutions in LightTable.

kristiandupont 13y ago
Agreed. I frequently mention Code Browser (http://tibleiz.net/code-browser/ http://tibleiz.net/code-browser/) which has multi-level folding that works very well. When I work solo on a project, I tend to fold many levels deep and create what would otherwise be a "smell" but it doesn't seem to cause problems. Unfortunately, I can't use it when working with a team because I know of literally nobody else who uses the editor. I've considered writing a plugin for LightTable or perhaps Sublime Text but I have no experience with either of their API's and I am not sure whether it would even be possible.

capkutay 13y ago

"We do not have a general purpose tree editor because trees are quite the complicated structure, and most valuable operations on trees require quite a bit of knowledge of what the tree represents." Definitely...Also, trees are pretty abstract data structures. You can imagine a min-heap as a tree but for practical purposes you can also think of it as an array where there are special rules for interacting with elements (adding, removing, finding the child of a node, etc). It could be a pain to try to generalize something so abstract and with so much room for complexity by making a tree editor... It's the same reason why UI's for software development haven't taken off. When something is that abstract and complicated, it's almost harder interacting with an interface that tries to 'dumb it down'. Not to mention the lack of control such interfaces would introduce.

JadeNB 13y ago
> Also, trees are pretty abstract data structures. You can imagine a min-heap as a tree but for practical purposes you can also think of it as an array where there are special rules for interacting with elements (adding, removing, finding the child of a node, etc). This seems to be a bit of a red herring: you can think of an array as a contiguous region of bare bits in memory where there are special rules for interacting with elements—and similarly for any data structure—but that point of view doesn't seem to be the most useful (except possibly, in the array case, for programming in C).

gcb0 13y ago

i don't agree. there are several representations for tree->text... but the tree itself are pretty much limited. cyclical, not cyclical. root node or loose. for an editor you probably don't even have to worry about the rest such as direction of traversal etc.

arethuza 13y ago

"We do not have a general purpose tree editor because trees are quite the complicated structure" Exactly - my response was basically - "We don't have a general purpose tree editor because we don't have general purpose trees".

agumonkey 13y ago

Opinionated lisp ~noob here. I tend to see sexps as a general tree and emacs+paredit[1] as a general tree editor, and even though I completely agree about your point on 'if you need folding maybe your design is wrong hence no need for tree structures'. I really feel limited whenever I use a non sexp based language. It's like having you're own little private refactorer at your fingertips. And even for small code it's a noted pleasure. [1] emacs or whatever program you use, as long as it give you tree walking keybindings.

jalanb 13y ago

"We are not designed to handle more than one layer at a time" anymore than we are "designed" to handle any source code format, surely?

adriano_f 13y ago

Lots of interesting points, but I disagree with the logic that "we are not designed to handle more than one layer at a time" necessarily implies that a tree-editor is impossible/undesirable. Yes, we are only built to think of an idea/code/story/essay at one "level" at a time. You are either thinking about the overall structure of the code, or a particular line. A particular scene, or the overall plot. But that's precisely why a tree editor, one that separates the levels for you, is so useful. You can always "zoom in" to the details by going right, and "zoom out" to the big picture by going left. Have a look at Gingko, for our approach to solving this problem: http://gingkoapp.com http://gingkoapp.com