An interesting idea that's definitely worth exploring.<p>However, I think the conflict between tree-based editing and normal editors is completely unnecessary. In fact, you can actually get basic tree-based editing <i>today</i> in Emacs!<p>The easiest language to support like this is Lisp because its syntax is about as close to pure tree as possible. And, indeed, Emacs has had structural editing for lisp for a while in the form of Paredit[1]. More recently, somebody extended this idea to Haskell[2] which is interesting because Haskell has one of the more complex, persnickety syntaxes around.<p>I'm not saying either of these are as good as dedicated editors—I'm not even convinced they <i>could</i> be as good—but they are low-cost ways to try these ideas out right now without abandoning general-purpose text editing or creating a brand new tool.<p>[1]: <a href="http://danmidwood.com/content/2014/11/21/animated-paredit.html" rel="nofollow">http://danmidwood.com/content/2014/11/21/animated-paredit.ht...</a><p>[2]: <a href="https://github.com/chrisdone/structured-haskell-mode" rel="nofollow">https://github.com/chrisdone/structured-haskell-mode</a>
This is really interesting, I'd love to see more about it. It's a shame they're not opening the source or at least putting up a public instance to test, I'd really like to give it a go.<p>I'd be very interested in some more detailed information about this. For example, I'd like to see a list of the hundred transformations required to edit JavaScript. They also mention that it is a home-row-oriented editor - what does that mean? Are the common commands available on the home row, such as navigation etc?<p>As the developer of a LISP IDE with structural editing functionality, this looks very interesting - please share more information!
Sounds like Prune lives in the same conceptual space as ParEdit for Emacs.<p>I have heard that ParEdit is a not a toy. I have heard that, if you work in a lisp-type language, it's worth your time.<p>Screen cast: <a href="http://emacsrocks.com/e14.html" rel="nofollow">http://emacsrocks.com/e14.html</a><p>More info: <a href="http://www.emacswiki.org/emacs/ParEdit" rel="nofollow">http://www.emacswiki.org/emacs/ParEdit</a>
I worked on a similar project for a while (the poorly-named Phlisped), and I came to many of the same conclusions as these guys did. A few notes:<p>I'm not sure reducing keystrokes is a useful measure. I can't think of a better one, though, so at least it's something quantifiable.<p>Pure tree editing, with no text editor to fall back to, is important. I didn't even use textual output, while it sounds like these guys did. They also used javascript, which is interesting since it has so much syntax. Lisp seems like a natural choice to me since the tree structure is readily apparent.<p>Dogfooding is critical, and it's very natural for a project like this. When I got to that point, I learned so much about what was really important in an editor. Like macros -- those helped so much.<p>Keyboard-based editing of trees is possible, but it takes significant effort to make it feel decently natural.<p>Collaboration is definitely the most important thing people in this area need to learn. There are dozens of projects similar to this one, and they're generally created by solo programmers (like I did) or by pairs (like Prune). Tree-based editing will never take off until a group of like-minded programmers gets together and makes it happen. I've been pulled away into an unrelated project, but if I were to come back to this, my first move would be to get some collaborators.
Interesting notion. I am inherently skeptical, because, like many I imagine (and as the article actually discusses), I am squarely in one of the text editor camps (which shall remain nameless to avoid anyone thinking I'm intending on a flamewar).<p>I am certainly open to the notion of alternative forms of interaction with code, but too often I see this take on the form of an IDE with “designer-like” capacities (this is not to say that IDEs are bad, just not what I am personally interested in) or the more simple interfaces used to teach kids to code (again, not a bad thing, just not what I want to use as my daily driver).<p>As others have said, it would have been great if they had open-sourced the code or offered a public instance so it could be vetted (even from an early perspective). And while I will do my best to keep an open mind, the macros available in other text editors seem like they may very well be capable of handling some of the functionality demonstrated in the article without much issue.
I think a big advantage to this kind of approach is the feedback you can get on your code - on-the-fly evaluation and type checking for example.<p>Here's my attempt: <a href="http://sediment.io" rel="nofollow">http://sediment.io</a>
I've been working on something similar for ClojureScript (Plastic editor package for Atom)
<a href="https://github.com/darwin/plastic" rel="nofollow">https://github.com/darwin/plastic</a>
How is it home row oriented? (Admittedly, I only used in-browser search for "home" and found nothing.)<p>Since moving from the home row has such a <i>massively destructive</i>, measured, and reproducedly measured effect on productivity and geek credibility, I've always thought that editors should accept no other keypresses than those on the home row. Every keyboard key that isn't caps lock, asdfghjkl;' or enter should be a key chord. (And not a key sequence, because that would not be productive: a real key chord.)<p>The next step is to release a physical keyboard that has exactly 10 keys, since moving the forefingers to press G and H, and moving the pinkies to press caps lock, apostrophe, and return is such a tremendous affront to good taste.<p>And editors should refuse to accept mouse input, as well. Ideally, touching the mouse would cause an electric shock, but that would require hardware modification.
A lot of the ideas expressed here are already available in a couple of the better Clojure development setups (known in Clojure as refactoring tools) -- since it is a lisp, that makes it a good language for implementing this stuff. However, in reality most Clojure devs are not taking advantage of all that this style of editing provides, partly because it requires more than the tool: it requires a different perspective on the code you write to think in this "refactor" way.
I <i>think</i> I can imagine what this is proposing, but it's really ambiguous to me. I'm kind of imagining a super autocomplete that's forced, always requires code to be in a valid form (barring TBD sections), and lets you navigate syntax/concepts instead of characters. I'm not sure what I'm completely missing though, as I'm sure there are some things.
I've spent a lot of time thinking about the fundamentals of code editing after building this: <a href="https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be&t=1m30s" rel="nofollow">https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be...</a> .<p>My main conclusion—which has a lot in common with the Prune editor—so far, came from asking, "what are we really doing when writing code?" and settling with, "selecting and configuring 'language constructs'". I believe this same thing can be done with generic models of languages/programs, where the source code is generated after the fact as a view (and that ASTs as 'program models' are unfortunately/unnecessarily coupled to a single view). I have a two-part, illustrated essay here: <a href="http://westoncb.blogspot.com/2015/06/why-programming-languages-dont-have.html" rel="nofollow">http://westoncb.blogspot.com/2015/06/why-programming-languag...</a>
Whoa, this is pretty cool. People have been trying to do this for ages. If they've been analyzing how people code, they have some valuable data to develop from. I hope they make it!
I once made a programming language with a tree editor: <a href="https://youtu.be/w5-g0Hps6bA" rel="nofollow">https://youtu.be/w5-g0Hps6bA</a><p>I had anyfix operators, so it was possible to write a program that read like english. In fact, I once got someone to write the sqrt function (inspired by the SICP) in Japanese: <a href="https://youtu.be/vwgvVpCRecE" rel="nofollow">https://youtu.be/vwgvVpCRecE</a><p>I think this is really promising to introduce people to programming. How many times have you heard someone say "programming is so frustrating! I always misplace my semicolon." Also, not having syntax means that people can use DSLs without having the pain to learn its syntax.
I came up with the idea of a structure editor independently. I am still very excited about the possibility but there are still some major challenges.<p>1) Viewing code in a tree can be much more verbose and require more cognitive load. I would much rather see "x = a + b" than (set 'x (+ a b)).<p>2) Languages contain syntactic sugar. Trees do not. That syntactic sugar goes a long ways towards making things easier.<p>3) Text based code can be very compact. Trees tend to require lots of space on the screen. They can be compacted using s-expressions but I've always found them cumbersome to read -- especially when things get nested.<p>4) Trees follow prefix format. Sometimes infix and postfix styles are much easier to read.<p>"someString" capitalize map fn<p>is much easier to read than<p>(map (capitalize "some string") fn)<p>Trees require you to descend to the leaf node and read backwards sometimes.
Also see <a href="http://concrete-editor.org/" rel="nofollow">http://concrete-editor.org/</a> (not my project, just linking to something I found cool)<p>Concrete does tree based editing with projections (a la Intellij Meta/ Simyoni's Intentional) so you can see visual layouts of state machines, etc that are just as editable as the textual ones.
I prototyped almost exactly this a couple years ago: <a href="https://www.timmclean.net/json-editor/" rel="nofollow">https://www.timmclean.net/json-editor/</a><p>I haven't had time to come back to it, so I'm very glad to see that other people are working on the idea!
Very interesting concept - this would allow the human and the compiler to actually work together from the same conceptual model, as opposed to the antagonistic process it is now.<p>Too bad the multi-billion dollar Facebook didn't actually produce any usable code to benefit the community, for a change.
I remember a game where you made circuit boards ... I think this kind of puzzle programming could work in low level programming, but for higher level, with millions of objects and layers of abstractions, it will be impossible.