22 ms·
Why Don't We Have a General-Purpose Tree Editor? (2014)
- amelius 10y agoDon't we have various LISP editors that are basically just that?
- m1el 10y agoEmacs has ParEdit minor mode which is a general-purpose tree editor. https://www.emacswiki.org/emacs/ParEdit https://www.emacswiki.org/emacs/ParEdit edit: paredit demos: Productive Emacs: Paredit https://www.youtube.com/watch?v=T1WBsI3gdDE https://www.youtube.com/watch?v=T1WBsI3gdDE Emacs Rocks! Episode 14: Paredit: https://www.youtube.com/watch?v=D6h5dFyyUX0 https://www.youtube.com/watch?v=D6h5dFyyUX0
- throwanem 10y agoMaybe link to the Emacs Rocks demo in future - just a thought. I share it because I've known about paredit for years and just kind of gone ¯\_(ツ)_/¯ and not bothered - but seeing that demo has sold me on the idea in a super big way, to the extent where it's going to impair my productivity today, or would if we weren't in a post-crunch breather. By comparison, the Emacs Wiki article is a poor introduction, because introduction is not its purpose; it's there to collect resources for people who already use paredit, and a good introduction answers the question of why someonr would want to start. That said, thanks so much for posting about it here! I'm really looking forward to learning it today.
- tambourine_man 10y agoYou mean this? https://youtube.com/watch?v=D6h5dFyyUX0 https://youtube.com/watch?v=D6h5dFyyUX0
- m1el 10y agoThanks. Added links to paredit demos.
- jamesrcole 10y agoHow good is it? I've never used it and I'm genuinely curious.
- m1el 10y agoIt depends on your requirements. ParEdit limits you to only perform AST transformations, which could be very good if you edit s-expressions or explicitly tree-like structures. If I was working on lisp-like languages, I would definitely use it. But ParEdit didn't stick to me, even after a few attempts. I didn't like the key bindings, and I think that the interface is too complex for me.
- torrent-of-ions 10y agoIt's definitely written with the intent of using it to edit Lisp code, and for that it is great. It is now hard for me to imagine writing Lisp by editing S-expressions directly.
- TeMPOraL 10y agoPretty good, it almost make you feel you're working on trees and not text. Takes a few moments to get used to. I recommend what I did: take a bunch of Lisp code, strip it out of parenthesis (M-x replace-string, replace ( and ) with empty strings), and then use Paredit commands to restore the original tree structure. I spent less than an hour simply doing this exercise again and again, and it was enough to become a proficient user.
- mej10 10y ago
- deleted 10y ago[deleted]
- bitexploder 10y agoDon't forget org mode or mind mapping software. Both are quite able with hierarchical data.
- charlieflowers 10y agoCan you (or anyone) name some good mind mapping software (other than org mode)?
- 50CNT 10y agoWhen I'm not using orgmode I usually use yED[0] for diagrams and graphs. Not specifically mind-mapping software, but close enough for my purposes. [0]https://www.yworks.com/products/yed https://www.yworks.com/products/yed
- bitexploder 10y agoFreemind is alright. Java. Does the basics. Runs everywhere. Open source.
- tolas 10y agoMind maps are really just nested lists right? https://workflowy.com/ https://workflowy.com/ is one of the best nested list (tree) editors I've found for mind-mapping and note-taking.
- problems 10y agoIt also has org-mode which seems fairly similar, but offers additional (optional) features for doing things like tables and due dates within the tree. I pretty much just use indented text trees for all but the most complex parts of software design and I find it works very well.
- vram22 10y ago>indented text trees You mean points and sub-points? >all but the most complex parts And what do you use for those?
- throwanem 10y agoI think we don't have a general-purpose tree editor for two reasons: 1. Nobody knows what it should look like. 2. Nobody knows how it should work. I fear this article has left me as much in the dark on these points as I was before I read it. Perhaps someone else here will find something in it I missed.
- supergreg 10y agoFWIW the editor in Chromium's and Firefox's developer tools are pretty good. I'd really like to see something like that as a standalone tool for both trees and XML and see how far it can be taken.
- throwanem 10y agoThe inspector? I've seen and worked with similar tools for XML, too, though not recently. They're very good for small, constrained hand-editing, but I find them to scale extremely poorly.
- therealmarv 10y agoFor XML you may want to take a closer look at XML Marker 1.1 (it's old, freeware and Windows but still better than many other tools) and maybe Eclipse.
- dTal 10y agoI think that sums it up. We really can't top crufty old Windows freeware? There is a gaping hole in the market.
- therealmarv 10y agoThe last time I worked on complex XML I even used XML Marker with WINE... it works there. If you want the Mercedes of XML editors you should take a look at Oxygen XML editor (this is not free but runs on more platforms than Windows).
- singularity2001 10y agoBlasphemy: All xml editors are General Purpose Tree Editors
- freeduck 10y agoPretty much any code editor with a jump to source, is a user friendly graph editor. And with refactoring tools, a good debugger and compiler I can't see what is missing
- throwanem 10y agoNot all graphs are expressed as code, or should be.
- TeMPOraL 10y agoAlso, code in most languages is pretty far from being a tree on the surface. Not to mention that "jump to source", et al. depend on particular semantics of the code. So by itself, those features don't make a general-purpose tree editor.
- nathell 10y agoThis reminded me of Leslie Lamport's (of LaTeX fame) paper "How to write a 21st century proof" [0], where he argues that we should explicitly structure proofs as trees. [0]: http://lamport.azurewebsites.net/pubs/proof.pdf http://lamport.azurewebsites.net/pubs/proof.pdf
- stupidcar 10y agoWe do: http://strlen.com/treesheets/ http://strlen.com/treesheets/
- jaked89 10y agoYou can also create a slideshow from it: https://github.com/YaakovDavis/TreeSlides https://github.com/YaakovDavis/TreeSlides
- throwanem 10y agoI should take a look at that, in case there are features there that org-mode doesn't already have and are worth stealing. More seriously, that looks like at least a sizable subset of org-mode's capabilities, implemented in a way that doesn't require clearing the hurdle that getting comfortable with Emacs tends to be. How is it on the import/export/interop side?
- Filligree 10y agoNever mind Emacs, Emacs is easy. Org-mode itself seems like a tool where you have to read fifty pages of documentation to make good use of it. Maybe I'm exaggerating, but I've tried it a couple of times, and it never seems to be worth the complexity penalty vs. using a plain text file.
- throwanem 10y agoIt depends what you mean by "good use", I suppose; I started out with just the very basic outliner and checklist features, and expanded from there. It didn't take much more than knowing those features existed, and what they looked like, to start using them. You do need to refer heavily to documentation when getting started with more complex features, but that seems like a fair tradeoff to me. I'm also not sure what you mean by "complexity penalty vs. using a plain text file", since Org files are plain text files, with all the magic implemented in the UI layer - I regularly edit Org files on my phone with Editorial, and while the UI is obviously rudimentary by comparison, such editing is not actually difficult to do. Will you elaborate on what you mean here?
- arc_of_descent 10y agoThanks to this post I found out about TreeSheets. Looks interesting.
- abhishivsaxena 10y agoCheck gingko, which is more focussed on docs, but is a tree editor at its core. https://gingkoapp.com/ https://gingkoapp.com/ Used it at university for notes, and is great for quick revisions before the exams too!
- shanusmagnus 10y agoGingko is phenomenal, heavy use of it will alter how you think and work, Sapir-Whorf style. Developer seems like a good guy who cares intensely. Happy to pay for this tool.
- baldfat 10y agoLooks great but it only does text. The link speaks of beyond ASCII. For this the old school PIM were better at storage of thoughts.
- ivan_ah 10y ago+1 for gingko -- it's especially great when starting a big document from scratch as it allows you to move and restructure entire documents, something that would be a lot of trouble with copy paste.
- rexpop 10y agoWhoops, I am a bad community member and posted before seeing this. Yeah, Gingko is really phenomenal, especially for multiplayer!
- jokoon 10y agoIsn't XML already a tree? Joke aside, graphs are far from being trivial to represent as a data structure, and their use are so various that you can hardly edit a graph using text alone. Even a visual editor would require to be tailored to different work you do with graphs.
- janci 10y agoSomewhat related: I was overwhelmed by complexity of web CMS solutions. I needed something very very simple, that gets the task done (user-editable webpage content). I represent the web by a tree, every node has metadata (id, type, title) and data. Nodes can be persisted (ie. as json text files, or in database table) and browsed (parent to children and back). Admin UI is very simple: in the left pane there is the tree browser, works like filesystem browser - you can open "folders" (nodes with subnodes) and "files" (leaf nodes). Each node shows specific editor for it's type, that usually consist of few form fields.
- halotrope 10y agoI had to work with Pimcore CMS recently (https://www.pimcore.org/en https://www.pimcore.org/en) and was pleasantly surprised. It works like you describe, the data is organised very developer friendly (classes and collections of data a tree structure for organisation). I am not sure how regular people would get along with this but knowing only bloated, slow and clumsy wordpress in that space it was surprisingly efficient.
- tim333 10y agoI'm not sure how you'd get that simple enough for users? For example if you do inspect element in Chrome it shows the page as a tree structure and it's not simple. Here's some of it for your post http://imgur.com/a/svB4J http://imgur.com/a/svB4J I couldn't get the full 14 level tree to fit on my screen.
- buovjaga 10y agoIf I understand you correctly, ProcessWire has such an admin UI out of the box: https://processwire.com/ https://processwire.com/ You can build your own admin UI, if you want as it's all done with the same API you use to build your sites.
- qznc 10y agoCa. 15 years ago, I used WebSiteBaker [0]. The website survives happily without any maintenance from my side. Only non-technical users changing content. There are a few minor things to do (e.g. CSS for mobile users), but I have no access anymore. I have no idea, how it has changed, but I would definitely try it again today. [0] http://websitebaker.org/ http://websitebaker.org/
- Philipp__ 10y agoThis certainly is good question. But, the fact that we don't have one yet maybe tells us that we haven't defined what it should be and what kind of problem it should solve. I mean, I like the idea a lot! Used MindNode, but I found it very bound to specific type of problems. It is visualization tool. And Emacs is just too much. I use it from time to time, but I would like nice native general purpose text editor with Tree capability and Markdown support.
- deleted 10y ago[deleted]
- l0ner 10y agoWhat comes to my mind is the Eclipse Modeling Framework. It's not exactly light-weight, but it always worked pretty well for my use cases. Throw a model at it (XML schema, annotated Java, ...) and it generates a Java implementation including a tree-based editor; certainly good enough for prototyping purposes.
- jventura 10y agoI'm curious about your use cases, as I do not seem to find much information about model-driven development out there. Can you elaborate a little bit more about what you do with EMF? I'm asking this on the perspective of someone who is about to teach model-driven software engineering for a semester but cannot find much pratical use for it..
- panic 10y agoBecause we don't have a general-purpose tree file format.
- selectnull 10y agoXML?
- bullen 10y agohttp://rupy.se/logic.jar http://rupy.se/logic.jar More than tree structured XML, this also provides node graph XML visual editing.
- rusk 10y agoI'm not being facetious here ... but aren't XML, Json and Yaml popular tree-structured formats? Like OP mentions Excel for instance, for editing tabular data, which isn't quite a standard file format, and in any case supports many different formats for tabular data. I can't help but wonder if OP is focusing on "format" rather than the structure of the data itself. There's plenty of editors for these well known formats. Perhaps he just needs to restructure his problem to use one of these? In XML for instance, it's fairly straightforward to implement a "plugin" such as he describes, using python or ruby and a DOM parser, which could amongst other things provide the different renderings described. I remember using XML Spy a long time back which seemed to do this quite well, as an ever expanding grid of cells, click into a cell, and it would expand showing its constituent cells. There were different tree representations available as well.
- al2o3cr 10y agoFWIW, comparing my experiences with several different "graphical equation editors" (fundamentally a flavor of tree-editor) versus editing LaTeX code directly, the tree editor loses every time. Yes, the tree editor is capable of providing an amazingly efficient interface for modifying parts of an existing expression - but when you start restructuring the whole expression things get messy fast. The plain code method is a bit rougher to read / enter in simple cases, but since it's just text in a text editor it doesn't have the same complexity escalation when doing unusual reorganizations.
- jessriedel 10y agoThis sounds like something that can only be true for equations below some size. If you're trying to manipulate a sufficiently large equation, it has to be automated, so directly editing text is bound to lose (however clunky the automated method may be). So maybe your experience is just that equations rarely get large enough to make it worth it to use a graphical editor? For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? Even if one only needs to use one or two functions with a very obvious tree interpretation (e.g., distributing multiplication over addition), Mathematica beats TeX for large enough equations. What graphical equation editors have you used? This was what turned up when I searched google: http://equalx.sourceforge.net http://equalx.sourceforge.net
- leni536 10y agoI regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines. \begin{equation} H_n(i) = \begin{cases} \left( H_{n-1}(i)_2, H_{n-1}(i)_1 \right) & 0 \le i < 2^{2(n-1)} \\ \left( H_{n-1}(i-2^{2(n-1)})_1, H_{n-1}(i-2^{2(n-1)})_2 + 2^{n-1} \right) & 2^{2(n-1)} \le i < 2 \cdot 2^{2(n-1)} \\ \left( H_{n-1}(i-2\cdot2^{2(n-1)})_1 + 2^{n-1}, H_{n-1}(i-2\cdot2^{2(n-1)})_2 + 2^{n-1} \right) & 2 \cdot 2^{2(n-1)} \le i < 3 \cdot 2^{2(n-1)} \\ \left( - H_{n-1}(i-3\cdot2^{2(n-1)})_2 + 2^{n}-1, - H_{n-1}(i-3\cdot2^{2(n-1)})_1 + 2^{n-1}-1 \right) & 3 \cdot 2^{2(n-1)} \le i < 4 \cdot 2^{2(n-1)} \\ \end{cases} \end{equation} > For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? I use Mathematica, and I just use the plaintext Mathematica syntax for large equations too. I also break these into multiple lines.
- elcapitan 10y agoThis may sound cruel, but you can use OmniOutliner as a tree editor and transform the XML to your target with your favorite xml transformation method.
- deckar01 10y agohttps://github.com/gephi/gephi https://github.com/gephi/gephi > Gephi is an award-winning open-source platform for visualizing and manipulating large graphs.
- mrmondo 10y agoI use Gephi quite frequently, it's interface leaves a bit to be desired but I've quite often quickly dumped some data into it and come up with some interesting relationships I wouldn't have thought of until it was visualised in Gephi.
- deckar01 10y agoIt would be quite possible to develop a plugin that provides a user input oriented editing experience.
- tonetheman 10y agoLittle Outliner 2 is pretty good. http://littleoutliner.com/ http://littleoutliner.com/ Made by Dave @ scripting.com
- mrmondo 10y agoWent to try it out but it requires signing into your twitter account and they get access to: - Update your profile. - Post Tweets for you. That's not cool.
- aethertron 10y agoVersion 1 doesn't require you to sign in: http://littleoutliner.com/v1/ http://littleoutliner.com/v1/ It saves a single document in your browser's local storage.
- matthewn 10y agoOWL is a nifty fork of Dave Winer's work that stores all data locally and doesn't require a Twitter account. https://github.com/interstar/OWL https://github.com/interstar/OWL
- tonetheman 10y agoThat looks interesting. It also has a web.py server that can be used to store data on a server somewhere. Good stuff.
- jonsagara 10y agoI'll second LO2. I use it to keep notes of what I do every day.
- staz 10y agoIs it me or is this article reposted every four months? Does it show that there is a fundamental need that is still unmet?
- audunw 10y agoI'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 or less), which is easy for text. But as soon as you want to move to useful, common tree-structures, you have to agree on both representation and semantics, which makes it much harder. One challenge we need to solve is - what level do you want to work on? Let's say you're working on some code. You may want to treat functions and blocks as a tree structure, but you want to treat simple mathematical expressions as text. Where this threshold is, is entirely context-dependent. The editor needs to understand the language and be able to expand text into its tree structure, or collapse the tree into its text representation, at any node in the tree. This implies that we need to agree on a common format for defining the conversion (parsing and generating) between text and trees. We'd probably also need a package system which contains common definitions for all major languages.
- melloclello 10y agoI've also been thinking about this for about as long (read this same article about 2-3 years ago), and came to pretty much the same conclusion. I actually think defining the grammar for turning text into a tree is likely to be the easy part, compared with building the editor itself. That said, during my research I ran across an ancient Usenet thread from 1989[1]. In it, the OP asks: > Should the language designers be making work for the language-oriented editor designers or should the language-oriented editor designers be making work for the language designers? (The thread rapidly devolves into an all out flame war about whether or not C can be considered to be context-free) Lisp feels like a language designed specifically to make a language-oriented editor designer happy, but most other popular languages fail the context-free test one way or another, thus making them difficult to define good grammars for. The problem seems to be that historically the language designers have far outnumbered the language-oriented editor designers. [1] https://groups.google.com/d/msg/comp.lang.misc/MCZmQv56--Q/OxFMkoAkv6sJ https://groups.google.com/d/msg/comp.lang.misc/MCZmQv56--Q/O...
- osxman 10y agoJoe Celko's Trees and Hierarchies in SQL for Smarties (book) is a good start for better understanding/defining trees. http://a.co/9eVzvji http://a.co/9eVzvji
- petepete 10y agoThere's a very useful chapter in Karwin's SQL Antipatterns on this topic too.
- jacquesm 10y agoThis has been here before: https://news.ycombinator.com/item?id=7511979 https://news.ycombinator.com/item?id=7511979 It's an unresolved problem as far as I know. Lots of partial solutions. I ran into this again recently because I use tree editors extensively (mostly leo) for my daily routine and was searching for a better (more structured) replacement but I haven't found anything yet that beats leo. Emacs org mode is reportedly extremely powerful as well but I have yet to invest significant time into it (there is only so much time...).
- progman 10y agoI use org mode every day. It actually is a tree editor. You can fold and unfold entries, move whole subtrees into deeper/higher levels, etc. The tree editor however is just one of many org features.
- stakent 10y agoTry spacemacs [0]. Emacs with IMHO better keybindings, lots of integrated packages which can be switched on/off as functionally related "layers". For vim users has of course evil package. [0] http://spacemacs.org/ http://spacemacs.org/
- wdfx 10y agohttp://www.yworks.com/products/yed http://www.yworks.com/products/yed and GraphML ?
- smarinov 10y agoyed is the best tool for the job I've used so far, so I'm glad someone already mentioned it.
- wdfx 10y agoI have found it most handy for visualising data that I've dumped elsewhere in a simple format such as .tgf (generated dependency diagrams etc).
- orless 10y agoI second this. I'm using yEd a lot, and I especially like layouting functions like hierarchical layout. I often use it to plan interdependent tasks. I just start with tasks I know are required and the thing of their prerequisites. Quite fast this gives a big graph structure. Then I run a hierarchical layout on this and suddenly I have a very clear structure of tasks. Their hierarchical layouting algorithm is great. I suspect it may be based on GraphViz dot's algorithm (http://www.graphviz.org/Documentation/TSE93.pdf http://www.graphviz.org/Documentation/TSE93.pdf) as it produces results of similar high quality. I also love the UI of yEd. Zooming in and out, creating nodes and dependencies/edges feels just great.
- bigmanwalter 10y agohttp://jsoneditoronline.org/ http://jsoneditoronline.org/ It's only for JSON but you can write a small script to convert it to whatever format you want.
- deleted 10y ago[deleted]
- fiatpandas 10y agoArchitects and the like already work with a really great tree editor called Grasshopper. Easy to see cross sections through your tree as you are arranging components and relationships L->R or T->B, so there is potential to have very clear hierarchies depending on the style of the user. Also, I've been impressed with a lot of the invention that has happened around Grasshopper's UX + UI. I've been really surprised to see the design community emerge with the best graph programming editor, as opposed to something much more developer focused. It is of course not general purpose because you have to have Rhino to use it, but it can be used for general purpose programming since you can create custom components with .NET, ignoring most of the pre-built ones that are focused on parameterized geometry.
- digi_owl 10y agoI must admit i have no clue what the author is actually asking for. If he is asking for away to organize various bits of text etc, is that not basically a directory tree stuffed with files?
- neonnoodle 10y agoSee 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 ....)
- lebski88 10y agoThis is a part of what we're working on at atomist - https://www.atomist.com/ https://www.atomist.com/ We're imagining the idea that your whole development flow is expressible in terms of trees and expressions that we can use to navigate those trees. Say for example a webhook pushes a commit event. We can navigate from that commit, into the chat channel associated with it. Find the repo that contains it. Associate it with the build and link the two together in chat or, most relevant to this article, navigate into the code itself and perform an action such as changing the code or opening a PR with a suggested edit and comment. The interesting thing is that it's trees the whole way down. We can use the same expression to reach across all all kinds of events or to pick out individual tokens or structures inside the code. There's lots of information on our blog: https://the-composition.com/ https://the-composition.com/ We've open sourced a lot of our core work at: https://github.com/atomist https://github.com/atomist and are also interested in talking to teams about joining out alpha (see atomist.com) It's a really interesting problem to be working on.
- d0lph 10y agoWorkflowy is pretty nice, it exports to plain text and xml. https://workflowy.com/ https://workflowy.com/
- baldfat 10y agoWorkflowy is a list manager or am I missing something?
- svachalek 10y agoNested lists == trees
- kibrad 10y agothat's an excellent option
- justanotheratom 10y agoI wish for something more sophisticated than workflowy, but I can't stop using it!
- iza 10y agoTry https://dynalist.io https://dynalist.io
- juliend2 10y agoI tend to use https://www.omnigroup.com/omnioutliner/ https://www.omnigroup.com/omnioutliner/, but workflowy is especially useful when I need a list to be shared. I also like mermaid (https://github.com/knsv/mermaid https://github.com/knsv/mermaid), so I created a small rails app (https://github.com/juliend2/metaglue https://github.com/juliend2/metaglue) that uses mermaid as the graph language, and it generates an SVG graph in realtime. I really like it and use it as a kind of brain dump for various subjects. The idea behind it is to collect any kind of data (bits of knowledge) and mash them all together inside a common graph.
- Toenex 10y ago
- peterhil 10y agoThere is the Dot language: https://en.wikipedia.org/wiki/DOT_(graph_description_language) https://en.wikipedia.org/wiki/DOT_(graph_description_languag... The files can be viewed with Graphviz.
- goerz 10y agoIsn't this just what's known as an Outliner (e.g. OmniOutliner, but various other programs exist)?
- kibrad 10y agoseems like the next trello can be trello with graphs, diagrams and trees
- RushPL 10y agoAuthor of code2flow here (https://code2flow.com https://code2flow.com) - I think you could use my tool to easily create many types of trees. It's not generic, as in, it is focused on charting programs/algorithms and workflows but I've seen people (ab)use it for many different use cases, like so: https://code2flow.com/fRRlCK https://code2flow.com/fRRlCK
- deleted 10y ago[deleted]
- loevborg 10y agoI'd even be happy to have just a simple general-purpose text-ui tree viewer. There's tree(1) and ncdu(2) but they doesn't really work for anything except directory trees.
- dahart 10y agoOne huge question to ask is why you need an editor specifically for a tree. Do you want a gui, or a format? If you need a gui, you are automatically in domain-specific territory. If you only need a format, maybe you don't need a tree editor at all. Excel is a great tool for making trees; just add a column that names your parent. I used Excel to create a prototype of an event driven animation sequencing engine for a Disney game. It was more of a state machine / directed graph than a tree, but the only constraint there is data, not the editor. The prototype was later replaced (after the game using Excel shipped) with a gui based tree editor, but not something that could be called "general purpose". I've long thought that hierarchical file formats come with some pretty bad downsides, from both sides, usage and implementation. You don't need a hierarchical format as long as you are willing to name all nodes and not allow anonymous nodes. Once you do that, you can have a flat file structure with fields that reference other nodes. Once you do that, XML feels crazy. Easier to implement parsers that don't have to do overblown amounts of dynamic memory allocation, easier for humans to read & follow, easier to share references or allow non-tree structures, etc. etc.
- weberc2 10y ago> If you need a gui, you are automatically in domain-specific territory. The author specifically describes a platform in which domain specific concerns are facilitated by plugins, so I don't see why we are "automatically in domain-specific territory". One could easily envision classes of plugins for drawing nodes and edges (perhaps a canvas DSL), plugins for enforcing the domain's specific rules, etc.
- dahart 10y agoI appreciate the reply, but I humbly suggest that nothing is solved by saying "just use plugins". You can't build a good plugin architecture in the first place without understanding the problem domain & workflow. This is not a new idea, people have tried it before. If there was a decent solution it would already exist. People have tried to make general purpose graph editors & tree GUIs & layout engines, and there have been a bunch of people that thought they were being smart by architecting it to accept plugins. There's a reason you've never heard of any of them; nothing was general purpose enough to stick around, and applications that didn't try to be "general purpose" have vastly superior UI/UX. I spent several years building a tree editor (the animation sequencing project I mentioned earlier). I've also used well known tree editors in node-based gui apps for decades. (Check out programs for film & game production like Nuke, Maya & Houdini -- they are tree editors.) Simply put, there are not enough commonalities between applications in different domains to make it worth building a shared "general purpose" editor. The workflows, problems, and schemas are too distinct. The tree isn't even close to the hard part anyway.
- GedByrne 10y agoFor the programming use case there is also Leo. http://leoeditor.com/ http://leoeditor.com/ Leo is of particular interest because it automatically syncs between the tree and code files: http://leoeditor.com/tutorial-programming.html http://leoeditor.com/tutorial-programming.html The approach is documented here: http://leoeditor.com/appendices.html#the-mulder-ream-update-algorithm http://leoeditor.com/appendices.html#the-mulder-ream-update-...
- BeetleB 10y agoLeo is fairly cool. Been around forever, but not many people know about it. I'm a heavy Emacs and Org mode user. But at this time I've given up on being proficient in Emacs-Lisp and how it ties to the whole Emacs ecosystem. So I searched for a self-extensible editor in Python, and find Leo. I haven't taken the time to learn it really well, but I did fiddle with some tree editing in Python with it, and it works as advertised. If I didn't have to work for a living, I'd spend most of my time porting over the cool aspects of Emacs to Leo. Unfortunately, the documentation/web site is very opaque. Not so bad that it's useless, but bad enough that if anyone wants to learn it well they'll have to do a lot of Google searching (in the mailing list) or code browsing. Also, to be frank, it's not a great editor compared to Vim/Emacs. But that should be easily fixable with scripting/code changes.
- deleted 10y ago[deleted]
- jerf 10y agoBecause the use case of "edit all graphs" is too divergent to be solved by one program. For simplicity, let me start with just trees. What kind of trees have we got? Well, we've got programming language ASTs. In these trees, nodes tend to have only two or three children, each of which is probably a short word or a number, but they can easily extend hundreds of levels deep, or even thousands. (Before you disagree with this, go take a look at the dump of the AST of a modestly complicated Python function or something. Many programming language grammars are not optimized for this representation and end up with way more intermediate grammar nodes than you'd expect, which all seem like they'd be really easy to "just" collapse, but that causes its own problems.) The naive and obvious representations of all of this are difficult to navigate and consume the vast majority of the screen with whitespace. It rapidly becomes clear you need a specialized mechanism for dealing with this... then after a few iterations, if you do it right, you discover that you've reinvented... the original textual representation. (This is not proof that textual representation is optimal in general. You can correctly argue that you end up there because the entire language was designed with that in mind in the first place, and that a language designed to be graph-based in the first place may work better. However, your tree viewer doesn't have any of the latter that doesn't already have a special-purpose viewer built for it, which your putatively generic code isn't going to compete with.) Database rows are just a graph, right? Well, that's one top-level node for the result that contains the rows, and then, oh, let's say 25,000 identically-structured children. How are you going to navigate that? Are you going to introduce a "paging" concept? If so, you're going to complicate the other uses of this generic editor that don't need it. How about rich text? Rich text is just a tree. But is your generic tree editor going to require sub nodes for "bold"? For that matter, how does your generic editor handle either of "text <b>bold</b> more text" or "text <span class='arbitrary_class'>span</span> more text"? There's a lot of different rules that people may want to apply to tree nodes; do those look like one, two, or three nodes in your editor? I can make a case for all three, for instance, for the first one (imagine the word bold is bold in the first one, it's a rich text display): * text bold more text * text (bold) bold more text * text (bold) bold * more text (Note the new asterisk on the third line of the last one; it's a new node. In the first one, we have "special" nodes that can be embedded, whereas others probably can't be; that's a heck of a concept to write into your generic editor and will have huge ramifications in all sorts of other places, not least of which is the graph data representation and API. In the second one we somehow have "embedded" nodes, which has the same problems, except it has different massive effects on the graph data structure and API. The third is conceptually simplest in a lot of ways, but maps neither to HTML nor to the human's internal representation very well.) Now, how do your choices that you made for this rich text application map back to the other types of graphs you may want to support? Because each of those three choices will have different implications if you then try to support RDF graphs in the same visual layout. Speaking of RDF... have you considered the visual differences between ordered trees and unordered trees? Box & line graphs naturally represent unordered children, outline views impose a view of order even if one doesn't exist, other layouts may have other consequences. You can't just let the decision about outline vs. box & line be determined by the orderedness of the nodes either, because there may be other properties of the graph that may be unsuitable for. And then, of course, there's the graphs that you want to view as box & line diagrams, the ones you want to have fully manual layout for vs. the ones you want some degree of automation. And you've to deal with the boxes that are way too big for the display because they contain several dozen kilobytes of plain text. Can your boxes contain subgraphs within them? And under any display methodology (graphs, outlines, whatever), what does it look like when you have a node with 25,000 incoming links? Does that work well with graphs that have only a few nodes like that? What about graphs like friend networks on Facebook that consist almost entirely of nodes that have hundreds of links? Note that when you've seen graphs of Facebook, they never much resemble, say, LabView diagrams, they're always these very zoomed-out representations with only entire regions colored and being discussed. How is your generic graph editor suitable for use on programming languages doing with this graph? The theme here is not "unsolvable problem". The theme here is "unresolvable conflicts between different use cases". In an individual context, these issues are solvable, and have been reasonably solved. But trying to create a generic "graph" editor is, well, given the genericness of the term "graph" basically trying to create a generic "editor".
- viach 10y agoIsn't that called Outliner?
- robochat42 10y agoI found myself thinking of something like Treeline when he describes what he wants. http://treeline.bellz.org/ http://treeline.bellz.org/
- slezyr 10y agoorgzly (open outliner saves in org mode for Android) https://play.google.com/store/apps/details?id=com.orgzly&hl=en https://play.google.com/store/apps/details?id=com.orgzly&hl=...
- bluetwo 10y agoHonestly, if I'm trying to organize some concepts into a tree, I'll go into Word, open a blank document, and switch to Outline mode. Not the most complex solution but also super easy to use. Tab to indent, shift-tab to unindent. Select-drag-and-drop... etc.
- chriswarbo 10y agoSurprised nobody's mentioned Boxer, or some other boxes-in-boxes representation http://web.media.mit.edu/~mres/papers/boxer.pdf http://web.media.mit.edu/~mres/papers/boxer.pdf Blockly ( https://developers.google.com/blockly https://developers.google.com/blockly ) is also similar, but I think it's a bit too specific: - Only one type of block is needed, to represent a generic "node" in the tree. Distinctions can be added by plugins, if desired for some particular language. - The idea of "interlocking" can be discarded, since a general tree editor should allow arbitrary edits to arbitrary trees (in the same way that a general text editor should allow any text to be inserted anywhere in a file/buffer). Plugins can add it back for particular languages. - Nesting should be the only relationship; it subsumes "sitting beside" (like Blockly assignments) or "wrapping around" (blockly loops). - No need to distinguish between editable/immutable values; everything is editable. As a baby step towards the author's goal, how about an s-expression editor which displays boxes-in-boxes instead of parentheses? The editing commands could be exactly the same as e.g. Emacs+paredit, the only difference would be that indentation begins at the left edge of the current box, rather than at the left edge of the screen. For example, we would have to discard the indentation of an expression like: (foo (bar baz) (quux foobar)) Instead we would align "foobar" to be in the same box as "quux", e.g. +-------------------------+ | +-------+ +---------+| |foo |bar baz| |quux || | +-------+ | foobar|| | +---------+| +-------------------------+ Note that I don't recommend using ASCII to draw the boxes (except maybe as a proof-of-concept). Once we have such an editor, we could start to extend it with features like coloured boxes for syntax colouring, structure-checkers (e.g. "if" should have 3 children, etc.). More radical extensions can then support pulling the boxes out into a more traditional tree structure.
- junke 10y agoIt's funny how bad I really want to go to the foobar line and hit Tab (or M-q near it).
- chriswarbo 10y agoAfter some Googling I've come across http://foldr.org/~michaelw/emacs/ http://foldr.org/~michaelw/emacs/ which includes a hack for giving nested s-expressions different colours and hiding the parentheses. This sort of "tree view", combined with paredit's "tree editing", might go some way towards faking a tree editor. Maybe this could be combined with https://github.com/jacksonrayhamilton/context-coloring https://github.com/jacksonrayhamilton/context-coloring and either https://en.wikipedia.org/wiki/Semigraphics https://en.wikipedia.org/wiki/Semigraphics or the new cairo support for drawing pretty borders?
- samirillian 10y agoI think this problem is closely related to the perennial "optimal to-do list" problem. A to-do list is a tree. If you have a good tree editor, you have a good to-do list app.
- chriswarbo 10y agoI think it's important to distinguish between "tree-structured data" and "tree-structured UI"; many of the suggestions here and in the article's comments mention s-expressions (or alternatives e.g. using indentation or similar); many others mention diagramming/mindmapping tools. I think the real issue is how disconnected such approaches are from each other: why can't I press a key and have my parenthesised expression be expanded into a tree, or press another button to collapse a sub-tree down into a parenthesised expression? I imagine a decent tree editor would let me: - Navigate and edit the structure and its contents in a linear representation, like using paredit on an s-expression. - Navigate and edit the structure and its contents in a more "tree-like" representation, e.g. as boxes+arrows, or nested boxes. - Toggle between display modes on a per-term basis, e.g. using boxes+arrows for the top-level (say, function definitions in a Lisp file) and s-expressions for the contents. - Fold/unfold terms/trees (code folding, but for expressions rather than lines) - Allow plugins/preferences tailored for particular trees, e.g. syntax colouring for programming language parse trees. As a more elaborate idea, we could allow plugins to extend the tree/graph structure with "virtual" nodes, e.g. linking names to their definitions, documentation, tests, etc. as if they were code-folded parts of the source code.
- junke 10y ago> Fold/unfold terms/trees (code folding, but for expressions rather than lines) Emacs can hide/show blocks in Lisp expressions (and others). Install HideShow (https://www.emacswiki.org/emacs/HideShow https://www.emacswiki.org/emacs/HideShow). I personally never use it, generally the right solution is to refactor (but there might be good use cases too). > As a more elaborate idea, we could allow plugins to extend the tree/graph structure with "virtual" nodes, e.g. linking names to their definitions, documentation, tests, etc. as if they were code-folded parts of the source code. Basically, when working from Emacs through Slime, the Common Lisp backend (called Swank) injects such metadata to the runtime objects (source file if a file exists, original code, documentation). You could define your very own properties if you want, like how a particular form should be displayed to the user. What already exists, for example, is a way to define custom indentation rules for macros, which are used on the Emacs side to indent your code as you wish. Slime also decorates values in the buffer so that they act as "presentation" objects (https://www.common-lisp.net/project/slime/doc/html/Presentations.html https://www.common-lisp.net/project/slime/doc/html/Presentat...).
- solomatov 10y agoWe have it. It's called JetBrains MPS: https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/
- haldean 10y agoInterestingly, visual programming and tree-editing has actually gained a lot of traction with non-programmers. Tons of the big video and audio production suites (off the top of my head: Houdini, Max MSP, Grasshopper, Nuke, Blender's node editor) are DAG-based authoring tools, and are a joy to use. As a person interested in programming language design, that makes me wonder if visual programming might be the sort of thing that we as programmers don't use because it is, in some sense, "beneath us". You can argue that the complexity of a standard Max patch is much lower than your production system, but many production systems are "render database to JSON", which seems far less complex than, say, a feature film, many of which are made almost entirely in Houdini.
- imode 10y agohonestly, let's go a step further and make it a general purpose graph editor! practical purposes abound, sure, but I'd just like to see the intermediate notation that pops out if someone were to attempt to design one. I don't think it'd be like graphviz..
- rijoja 10y agoDid anybody get the source code to run? I've been trying to test it out for a long time but never really gotten anywhere. Is there anybody that is good at functional programming that could help me out? It's surely funny if there can be so many comments and nobody even ran the program.
- ChicagoDave 10y agoI have a startup called Wizely, which is a social wisdom network. The iOS (phone) app (in development) will have a tree editor. I'm also developing a tablet version that would be bigger and more "touch-friendly". A full browser/desktop version isn't in the works, but if things roll out according to plan, it would be an important addition to our process.
- enord 10y agoWe do, it's called "the file system". Folders and directories galore. If you dont like folder icons and rectangular windows, navigate with MC. The problem is not trees, they are readily available in many formats. The problem is schemas. If there are no rules on the branches everything becomes "Old_stuff" or "important_work" or whatever people do to their document folders as the tide turns. You need trees layered over trees to provide some structure and get that sweet workflow QC. Graph-homomorphisms between trees that is, or slice categories over whatever structure you need to maintain. Trees (or graphs) in semantic/syntactic relationships stacked as high as you can muster. Usually this is presented as a two-layered structure-tree+data-tree system in end user applications, with a fixed semantic tree depending on the domain in application. The trick is finding the balance between end-user configurability of layers n+1 and the required knowledge to design useful structures. People who edit layer 2 should probably be domain experts, and layers 3 and above are best left to programmers and computer scientists. If this was a solved problem, nobody would buy CRUD-software, and a good half of us would be looking for work.
- mdemare 10y agoA tree is a pair of a value and a list of trees. The "list of trees" part is what's constant about trees; the value is what makes it hard. What's a value? A name? A string? A text? Either a text, or a name and a map of strings to strings (simplified HTML)? A General Purpose Tree Editor would have to handle all those cases, and a whole lot more.
- philip4534 10y agoFreeplane?
- rexpop 10y agoAnd then there is Gingko[1], a beautiful, keyboard-shortcutted, markdown-enabled tree editor that exports to html, markdown, LaTeX, docx, impress.js, and json. Gingko provide templates for Timelines, Screenplays, GTD and Academic papers, but I can imagine using it for complex formal proofs — I mostly use it for Microscope[2] and worldbuilding[3]. Right now it doesn't have any programmatic/computing capacity, but Gingko is eminently user friendly, so if Adriano[4] ever implemented a plugin system (or if someone wrote a Gingko-node-crunching chrome extension) I would imagine it to be a very enjoyable interface for editing trees. 1. https://gingkoapp.com/?ref=f32636d1 https://gingkoapp.com/?ref=f32636d1 2. http://www.lamemage.com/microscope/ http://www.lamemage.com/microscope/ 3. https://www.reddit.com/r/worldbuilding https://www.reddit.com/r/worldbuilding 4. https://twitter.com/adrianoferrari https://twitter.com/adrianoferrari Disclosure: I don't have any affiliation with Gingko, but that is my referral link. ;)
- Animats 10y agoThere have been pure S-expression editors in LISP. INTERLISP worked that way. Yet EMACS, which is a text editor which knows a little about S-expressions, won out. INTERLISP's LISP editor had features never seen since, such as "Make this code subexpression a standalone function". This would pull the subexpression out and make it a named function, inserting the correct calls with the correct arguments in the original code. The inverse operation, "expand this function here", was also available. This eased refactoring. There don't seem to be tree-oriented editors for XML. Or HTML. Or even JSON. That would be useful. At least the tree structure would always be correct. More effort is going into figuring out how to parse "bad JSON" than into writing editors for it.
- taeric 10y agoThis doesn't sound like a difficult macro/function to write. More, this has been replicated in other languages, now. These refactoring capabilities are considered a hallmark of the popular IDEs that people point to. And keeping HTML "well formed" is a battle that lost hard with xhtml. Further, any "rich" editor likely kept the tree structure well formed. It did little to keep it manageable, though. And I wager that most "bad JSON" is programmatically generated. This is literally a problem with countless solutions today. But, it is almost always quicker to println something out that you are certain you know the structure of, than it is to use a library. So, people don't. :(
- thfuran 10y ago>features never seen since, such as "Make this code subexpression a standalone function". This would pull the subexpression out and make it a named function, inserting the correct calls with the correct arguments in the original code. Isn't that a pretty basic refactoring feature of most IDEs?
- zubat 10y agoTrees are not all alike and I think this stops most such plans. Some trees have types and tags, quoting of other trees, container patterns that are representable as a tree but unpleasant to edit. And we get stuck on that and say "Let's have a syntax." And then we're back to text again.
- gcatlin 10y agoI don't want a general purpose tree editor. I want a general purpose text editor that understands the semantics of the text I'm editing. One that understands all the various not-necessarily-sexp-based code I'm editing is a tree and supports (ParEdit style) operations on that tree. Especially with languages in the Algol/C family. I think this can be accomplished (eventually) via language servers and editors that speak the Language Server Protocol (LSP) [0]. But I don't need a UI oriented around visually displaying tree-like things. Expanding / collapsing nodes is very meh. Moving / splitting / joining nodes is much more interesting and useful. As a simple concrete example: changing the order of the parameters (and their type) in a function definition. Wouldn't it be great to 'swap-with-prev-node' or 'swap-with-next-node' rather than copy/paste and dealing with commas? The same operations could swap the order of two fields in a struct or two functions or two classes or any pair of adjacent nodes in a tree. Or how about moving an 'if' block inside the 'for' block that follows it? Just execute the 'move-node-inside-next-node' (or whatever) command. This only requires editors that (indirectly) understand the semantics of the text you're editing. Thus far the biggest barrier is all wheel re-invention needed for the cartesian product of all editors and all languages. But that's the wrong approach. We need each language to provide a tool that each editor can use via a common protocol. This is precisely the point of the LSP. The functionality only needs to be written once per language and per editor. This is totally tractable. I don't know if LSP currently supports the specific tree-manipulation functionality I mentioned, but I'm confident it could. Does anyone knowledgeable about LSP know if this is already possible, feasible, and/or generally desirable? Are there deal breakers that make this hard / not worthwhile? [0] http://langserver.org/ http://langserver.org/
- chriswarbo 10y agoKeep in mind that it's pretty trivial (if laborious) to make parsers/pretty-printers between your language of choice and s-expressions, which would allow a generic tree editor to work on your language. Note that you don't need a fleshed-out, implementation-friendly abstract syntax tree (e.g. "(definition (name foo) (type (function int int)) (arguments ((name x) (type int))) (body ...))"); you just need a parse tree of the tokens (e.g. (def foo ((int x)) ...)). I agree that the existing silos of VisualStudio, Eclipse, Netbeans, jEdit, Emacs, Vi, etc. is a bad thing, and initiatives like LSP are is a step in the right direction. Another nice approach that I came across recently is https://github.com/CarlOlson/structured-editing https://github.com/CarlOlson/structured-editing . This also uses a separate process to get information about code, but uses "spans" (start position, end position, label, extra info) which seem to be in between strings and syntax trees. For example a span might encompass a class definition; another span covers a method inside that class; another covers a statement in that method; another covers a function call in that statement; another covers the function name in that call, and it's extra info includes the location where that function is defined, its type, etc.
- stcredzero 10y agoThe 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.)
- unhammer 10y agodef f = x = readline; g x def g x = print x; f
- jcao219 10y agoThe AST of that would still be a tree. AST does not concern itself with the semantics of the language, only its syntax.
- TeMPOraL 10y agoNot 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.
- thwee789 10y agoCheck out Freemind
- thwee789 10y agoCheck out Freemind. It's been collecting dust on the shelves.
- tunesmith 10y agoA lot of tree editors aren't sufficient because he's asking about DAGs. Most tree-editing software only lets you have multiple children per parent, but you also need to allow multiple parents per child. http://flyinglogic.com/ http://flyinglogic.com/ is on the right track. JVM cross platform and commercial. Curious how jetbrains MPS could improve on something like that.
- lowmagnet 10y agoThe author's use of "sufficient cause" brought to mind Sciral's Flying logic[0] which does some basic logic and sufficient cause in terms of Goldratt's Theory of Constraints. It's also useful for a number of other logical structures, like trees. [0] http://flyinglogic.com http://flyinglogic.com
- eschaton 10y agoLisp Machines had general tree editing facilities.
- charlieflowers 10y agoI 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 existence).
- ako 10y agoOutliners? (https://en.wikipedia.org/wiki/Outliner https://en.wikipedia.org/wiki/Outliner) Heavy user of outline view in MS-word here, which is basically a tree editor for text documents.
- holy_jeebus 10y agoIf you can do queries AND have a GUI option that seems logical to me. Looking back at my history this topic hits me right in the feels... http://birdhouse.org/beos/byte/25-formula_queries/ http://birdhouse.org/beos/byte/25-formula_queries/
- jcoffland 10y agoTrees 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.
- anigbrowl 10y agoHow do you feel about tools like Reaktor, which I assure you works very well indeed?
- jcoffland 10y agoReaktor is a audio program. There is actually a long history of this type of app working well. PD is an early example. This is indeed a limited type of programming. Above I was referring to attempts to apply this idea to general programming. I'm not saying such systems are impossible just that it's a bad idea to assume it will make the programmer's life easier.
- anigbrowl 10y agoThat's not very responsive. Reaktor's primary purpose is to produce audio, but it also allows one to build sequencers, user interfaces, graphics (eg spectrograms, from DSP primitives by build your own FFT modules) and all sorts of other tools. Besides, why is audio somehow an inferior sort of data processing?
- YeGoblynQueenne 10y ago>> 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.
- vog 10y ago> {{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)}}
- YeGoblynQueenne 10y agoThanks. Or you can always use what I think is slightly informal notation, where a directed edge is notated as a -> b (I've seen that in textbooks, but I'm not sure where it's coming from).
- vog 10y agoHaven't seen this notation in text books so far, but I guess one of the following 3 things happened: (1) The notation a->b was defined as a simple shorthand, i.e. a->b := (a,b). (2) The notation a->b was defined to be the graph consisting of just a, b and the edge, i.e. a->b := ({a,b}, {(a,b)}) ... this may be followed by some algebraic rules about how to combine small graphs to build larger graphs. (3) The notation a->b may be a somewhat misused notation for functions, meaning the only possible function from set {a} to set {b}, i.e. the function that maps a to b. If you define a function to be a relation (i.e. a set of pairs) where the first elements are unique, then this is acually equal to {(a,b)}, i.e. the set containing exactly this one pair. Interpretation (3) might look somewhat contrieved, but it actually isn't that much of a stretch, given the connections between graph theory and function structures through category theory.
- arxpoetica 10y agoI've brought up this issue before in the context of GraphQL's declarative data: https://github.com/facebook/graphql/issues/237#issuecomment-270195701 https://github.com/facebook/graphql/issues/237#issuecomment-...
- chriswarbo 10y agoSomething slightly more hardcode: http://hazelgrove.org http://hazelgrove.org - structured editing via a formal calculus of actions which provably maintains correctness. Whilst a cool idea, and a nice foundation for actions, it certainly suffers from being clunky UI-wise, so doesn't solve the author's problem directly.
- ClayFerguson 10y agoTo me it's shocking that there's nothing for editing XML that equates to an editable tree GUI interface where nodes and properties can be rendered onto something resembling a document but yet browsable (by expanding and collapsing node) with the same paradigm of a file-system browser gui. I'm working on this myself actually, in meta64.com (see it on github, because the site is not always live, and is experimental). I am using JCR as the back end data storage but seriously considering adding a feature so support direct XML editing. XML and also REST are highly structural, and yet everyone seems to just use syntax-highlighting text editors to edit them rather than something more akin to a tree-based browser, that would render something more friendly looking (with expand/collapse capability). Think of it like this, you have seen RSS XML before right? You have also seen web sites that RENDER the RSS feed into a document-looking thing. That's what i'm getting at. Going from editing this stuff as a text file, to something much more advanced, like a tree-browser. Maybe there are some things i'm not aware of, like perhaps even an Atom Editor plugin or whatever, but I don't think there's anything in wide use or i'd know about it, having been a web developer for 25yrs now.
- scythe 10y agoThink of this in terms of ordinal numbers. When you have text, you can interpret the string as a number and you can count the possible files: "0x01", "0x02", ... "0x0101", "0x0102", ... "0x010101", ... -- all of the possible files are enumerated by a single increasing sequence. This corresponds to the ordinal "omega-0". When you have a table, you can interpret each row as a number and now you have an arbitrary number of infinite increasing sequences, but you can imagine a transfinite "sequence of sequences" that counts the tables with 1 row, then the tables with 2 rows, and so forth. This is a single infinite increasing sequence of infinite increasing sequences, which corresponds to the ordinal "omega-0 squared". But when you have a tree, there's an infinite increasing sequence corresponding to... every single finite tree! In fact, there are multiple increasing sequences corresponding to every finite tree, and infinite sequences associated to those sequences, and... anyway, tree-counting functions are very hard to define at all, but with a little bit of work in combinatorics you'll find something called a "Veblen function" which is defined so that the parameter of the function is the number of levels of recursion of infinitary functions applied to themselves, and then the fixpoint of the Veblen function itself is the Feferman-Schutte ordinal, which cannot even be defined in first-order logic! One example of the horror that results from counting trees is Kruskal's theorem: http://en.wikipedia.org/wiki/Kruskal's_tree_theorem http://en.wikipedia.org/wiki/Kruskal's_tree_theorem In other words, trees, which can encode arbitrary structure, are much more difficult to do math on than tables and flat files, which can only encode simple structures.
- dustingetz 10y agoimagine you had about ten excel tables linked in a graph, any interesting visualization or analysis involves querying it like a database, and many databases are very rigid in terms what they can store, not flexible like excel. Semantic web stores (triple stores) are mostly schemaless and solve the rigidity but they had their own problems [1], datomic's 5-store model maybe fixes them? So maybe we will see an excel-for-graphs based on datomic someday soon. I'm working on this problem so if anyone has any interest in discussing this you should email me! It's a really interesting problem because excel-for-graphs would be an amazing starting point for building CRUD apps. [1] can anyone help me with clarity here as to why triple stores failed? Is it because no :db/retract and no time axis so cache consistency problems? or a deeper reason?
- lcedp 10y agoTake a look at Parinfer[0]. It's for Lisp editing, but S-expressions are as general as it gets. Also you can use Ranger[1] or Finder or NERDTree with Vim/Nvim to utilize your file system as a tree structure and afterwards "extract" it with tree[2] [0] https://shaunlebron.github.io/parinfer/#introduction https://shaunlebron.github.io/parinfer/#introduction [1] http://ranger.nongnu.org/ http://ranger.nongnu.org/ [2] http://mama.indstate.edu/users/ice/tree/ http://mama.indstate.edu/users/ice/tree/