Why Don't We Have a General-Purpose Tree Editor? (2014)

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by stcredzero on Monday February 06, 2017 @01:54PM (#13582687)

The key insight of this post for me is this: Code editing is tree editing! The reason why code is edited in text editors, is that tree editing interfaces are fundamentally difficult to do well, and often have to be carefully tuned to the properties of the particular trees and editing tasks. (Simple examples: Huge fanout vs. at most 2 children. Very large information-rich nodes vs. tiny nodes.)

In the early days of programming text editors, we dealt with this difficulty by exploiting the human brain's mechanisms for dealing with serialized trees -- which is to say the human brain's facilities for processing language and reading and writing text. By doing this, we could represent all kinds of hierarchically structured code, and let the human brain process it. But even in these early days, we started bringing in visual aids for reading structure: indentation and braces.

Now, if you look at modern IDEs, you'll find even more geometric/visual representation of the tree structure of code, in the form of collapsible tree controls operating on the code. This isn't to naively say that graphical programming is the way to go, since the potential for interrelation and complexity of structure in code is far too high to comfortably represent in 2 or even 3 dimensions. The way forward is to be able to dynamically visualize very specific contexts. (One example I can think of of the top of my head, would be to quickly visualize all "subscribers" of an Observer, then be able to visualize the 2nd order "users" of those subscribers. Another would be to visualize patterns in code supporting dataflows as an explicit flow graph.)

[ Parent | on HN ]

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by unhammer on Monday February 06, 2017 @04:44PM (#13584416)

def f = x = readline; g x

def g x = print x; f

[ Parent | on HN ]

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by jcao219 on Monday February 06, 2017 @05:31PM (#13584915)

The AST of that would still be a tree. AST does not concern itself with the semantics of the language, only its syntax.

[ Parent | on HN ]

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by TeMPOraL on Monday February 06, 2017 @07:16PM (#13585741)

Not 100% sure how to interpret this piece of code, but my naive interpretation gives this AST:

  (def f ()
    (let ((x (readline)))
      (g x)))
  
  (def g (x)
    (print x)
    (f))

Writing in Lisp can open one's eyes about the underlying structure of the code.

[ Parent | on HN ]

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by unhammer on Wednesday February 08, 2017 @06:07AM (#13597377)

My point was that "Code editing is tree editing" sounds a bit like if you can understand the syntax tree, you understand what the code does – which isn't true here. Trees don't show the recursion[1], and a tree-view of code (with e.g. folding) might even give a false impression that what's inside one branch is somehow self-contained. Ie. Turing Machines are more expressive than CFG's :-) Not that tree-view's aren't helpful (indentation is important, and editing Lisp with paredit is a real joy), but there's much more to code-editing than tree-manipulation.

[1] Unless your "tree"-view is actually a lazy call-graph …

[ Parent | on HN ]