Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pcmonk.me

Post reply on HN
Print view View original

171–180 of 222 posts

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

#171

Post by ako »

charlieflowers wrote: post #159

I have wondered this exact same thing! I assumed tree editors did exist, and I was excited that all I needed to do was go find them. But Google did not come through for me. Even a basic tree editor would be very powerful. Especially if you could run code from a repl that would change the tree (I know, that's no longer basic ... but it would let the graphical portion be basic, which might help it be bootstrapped into…

Outliners? (https://en.wikipedia.org/wiki/Outliner)

Heavy user of outline view in MS-word here, which is basically a tree editor for text documents.

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

#172

Post by junke »

chriswarbo wrote: post #151
junke wrote: post #137

Earlier quoted context omitted.

What'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 ....)

> 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".

> 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).

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

#173

Post by jcoffland »

Trees are graphs with out cycles but you always end up adding cycles. Code is no exception. There have been endless attempts to create coding systems based on graphs. These systems promise extraordinary modularity and reusability and an ease of programming which will allow anyone to construct complex software with a few clicks and drags. So far everyone of these systems that I have seen in the last 25 years has fallen short of its promises.

If you pay attention to these characteristics you will begin to notice the regularity with which such systems crop up and die. In my experience there's no use trying to talk enthusiasts out of this idea. I even attempted such a system myself many years ago. It's almost a rite of passage.

The reason tree editors (aka graph editors with out cycles, yet) don't work is similar to why we use relational DBs, instead of more the natural interpretation of data as graphs, boils down to, graph algorithms are slow and complex. In practice the added complexity outweighs the perceived benefits. The way people currently edit code, although not perfect, actually works really well. You have to weigh the costs of moving away from a simple system that works against the benefits and complexity of the new system.

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

#174

Post by mike_hearn »

audunw wrote: post #50

I've been thinking about this constantly for the last 2-3 years. I'm working on something which might lead to this. What I've concluded, is that we don't have a good representation for a general purpose tree editor to work on. Roughly speaking, S-expressions are just a bit too simple, and XML is way too complicated. General purpose plain text editors work so well because we've agreed on a common representation (more…

You should look at JetBrains MPS, as should everyone posting on this thread. Because MPS has been in development for over 10 years as far as I know, and has attacked and solved a huge number of the issues you raise here and many more too (e.g. how to integrate non-text based programming with version control).

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

#175

Post by bsenftner »

melloclello wrote: post #167
bsenftner wrote: post #161

Earlier quoted context omitted.

Back in '84 I was an undergrad at Boston University, doing an independent study with one of the business professors, Dr. Fedoritz, on a "next generation spreadsheet" that was to incorporate a cell-less freeform tree structure to represent Frames of Reference. Operating under the business school, we were working on advanced interfaces for financial professionals. The project was called a Frame Based Knowledge Represen…

Wow. I hope that didn't kill your project? I wouldn't mind seeing the UI, if you have any pictures, it sounds way ahead of its time!

I turned the project into another independent study and created a 3D animation language. About a decade later, I was introduced to the first feature film compositor centered around the GPU, called Shake, and it's node layout looked creepily familiar to how the Frame Knowledge System was when I last used it...

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

#176

Post by YeGoblynQueenne »

>> We need a solid, simple program that can simply edit trees.

I might be misunderstanding this but a "tree" is a graph, so formally a tuple G = {V,E} where V a set of vertices {a,b,c,....} and E a set of tuples: {{a,b}, {b,c},...} so that each a,b,c,... are vertices in V.

So for instance, the graph:

    a
    |
   / \
  b   c
  |   | 
  d   e
Would be written as {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied by a statement as to whether edges are directed or not.

That's a simple, intuitive, light-weight notation that is very easy to manipulate in a text editor, so that's probably why nobody has bothered to write a special-purpose program for it.

And if you want a graphical representation there's always tools like graphviz, so our graph can be written in dot-language as:

  digraph{ 
   a->b
   a->c
   b->d
   c->e
   }
Also, I don't understand why a tool to manipulate graphs, rather than just represent them, would be any different than a proof assistant or a theorem prover.

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

#177

Post by unhammer »

stcredzero wrote: post #149

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 pr…

def f = x = readline; g x

def g x = print x; f

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

#178

Post by [deleted] »

stcredzero wrote: post #149

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 pr…

[deleted]

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

#179

Post by vog »

YeGoblynQueenne wrote: post #176

>> We need a solid, simple program that can simply edit trees. I might be misunderstanding this but a "tree" is a graph, so formally a tuple G = {V,E} where V a set of vertices {a,b,c,....} and E a set of tuples: {{a,b}, {b,c},...} so that each a,b,c,... are vertices in V. So for instance, the graph: a | / \ b c | | d e Would be written as {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied b…

> {{V,E}: V = {a,b,c,d,e}, E = {{a,b},{a,c},{b,d},{c,e}}} possibly accompanied by a statement as to whether edges are directed or not.

From a math notation point of view, this statement is not needed. If your edges are directed, denote your edges not as sets (which are always unordered in math), but as ordered pairs instead:

{{V,E}: V = {a,b,c,d,e}, E = {(a,b),(a,c),(b,d),(c,e)}}

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

#180

Post by anigbrowl »

jcoffland wrote: post #173

Trees are graphs with out cycles but you always end up adding cycles. Code is no exception. There have been endless attempts to create coding systems based on graphs. These systems promise extraordinary modularity and reusability and an ease of programming which will allow anyone to construct complex software with a few clicks and drags. So far everyone of these systems that I have seen in the last 25 years has falle…

How do you feel about tools like Reaktor, which I assure you works very well indeed?
Post reply on HN