
Prune: A Tree-Based, Home-Row-Oriented Code Editor - KentBeck
https://www.facebook.com/notes/kent-beck/prune-a-code-editor-that-is-not-a-text-editor/1012061842160013
======
tikhonj
An interesting idea that's definitely worth exploring.

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
_today_ in Emacs!

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.

I'm not saying either of these are as good as dedicated editors—I'm not even
convinced they _could_ 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.

[1]: [http://danmidwood.com/content/2014/11/21/animated-
paredit.ht...](http://danmidwood.com/content/2014/11/21/animated-paredit.html)

[2]: [https://github.com/chrisdone/structured-haskell-
mode](https://github.com/chrisdone/structured-haskell-mode)

~~~
habitue
There is also js2-refactor [1] by Magnar Sveen (of emacs rocks fame) which
adds structural editing to js2-mode

[1]:
[https://github.com/magnars/js2-refactor.el](https://github.com/magnars/js2-refactor.el)

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

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?

As the developer of a LISP IDE with structural editing functionality, this
looks very interesting - please share more information!

------
daveloyall
Sounds like Prune lives in the same conceptual space as ParEdit for Emacs.

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.

Screen cast: [http://emacsrocks.com/e14.html](http://emacsrocks.com/e14.html)

More info:
[http://www.emacswiki.org/emacs/ParEdit](http://www.emacswiki.org/emacs/ParEdit)

~~~
mraison
I think coding in lisp-family languages without using structural editing (aka
paredit) is a significant waste of time. It takes maybe 2 hours to get used to
it. If you don't use it, you will spend more time counting and adjusting
parentheses than actually writing symbols, and you will spend more time fixing
bugs caused by bad parentheses than thinking about the logic of your program.
In addition, after you make the jump, you will never complain again about lisp
having "too many parentheses".

"If paredit is not for you, then you need to become the sort of person that
paredit is for. -Phil Hagelberg"

------
pcmonk
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:

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.

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.

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.

Keyboard-based editing of trees is possible, but it takes significant effort
to make it feel decently natural.

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.

~~~
dwc
I think reducing keystrokes is a proxy metric for reducing the time and
cognitive load of accomplishing an editing task. It's easy to measure, and
probably good enough to tell if you're getting anywhere, qualitatively. I
don't think it's good enough to quantify improvement in a meaningful manner,
though.

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

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

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.

~~~
kctess5
Out of curiosity, how do you deal with not having some of the things that IDEs
support?

I too am firmly in a text editor camp, but I've recently been basically forced
to use Eclipse while writing Java (ick) at work. The fact that it knows a lot
about the code is invaluable sometimes - auto-importing package names as you
type, fixing build rules in other files automatically, code completion, type-
definitions that appear with inline usage notes, etc. Granted, enterprise Java
in a build environment is the ideal use case for an IDE, but many of those
features are useful _all the time._ Now when I write other code, it feels
somewhat archaic that my text editor of choice isn't giving me function
docs/typedefs and managing dependencies as I write.

As much as I despise the text editor in Eclipse, living without those things
is basically impossible. I have "solved" this problem by constantly switching
contexts between my editor of choice and Eclipse, whenever I need to do
something crafty. What do other people do about this?

~~~
halosghost
Actually, many of the advanced text editors offer plugins that replicate a
variety of the functionality you mention. To better answer your question, I am
forced to reveal the text editor I prefer (please do not take this comment as
a slant to any other text editor): vim.

For vim, there are several plugins that provide completion functionality (for
various languages)[1]. There are things to deal with Java imports
specifically[2]. (I don't know what you mean by fixing build rules.) Hey,
there are even plugins meant to facilitate whole IDE functionality for some
languages[3].

Personally, I avoid things like Java so I have less of a use-case for IDEs
anyway. Specifically, I code in C and Haskell (and a touch of by-hand llvm-ir
for fun). In C, automatic imports and the like, I do not even wish for (since
it is so necessary for me to completely understand the function calls I make,
I need to read the docs quite commonly which mention the header for
#inclusion). And, for Haskell, I'm constantly prototyping in ghci, so I learn
what I need anyway. In neithr of these languages do I feel it is helpful
enough for me to desire such things. Having said that, I understand that many
people disagree; not too long ago, there was a small uproar that Haskell did
not have a proper IDE yet. And I am exposed to IDEs at $DAYJOB, but if
anything, that has further soured me towards them.

To all their own, text editors and IDEs alike; I think I'm likely to stick to
my text editor :)

[1]
[https://stackoverflow.com/questions/5169638/autocompletion-i...](https://stackoverflow.com/questions/5169638/autocompletion-
in-vim)

[2]
[http://www.vim.org/scripts/script.php?script_id=325](http://www.vim.org/scripts/script.php?script_id=325)

[3]
[http://www.vim.org/scripts/script.php?script_id=213](http://www.vim.org/scripts/script.php?script_id=213)

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

Here's my attempt: [http://sediment.io](http://sediment.io)

------
dr_win
I've been working on something similar for ClojureScript (Plastic editor
package for Atom)
[https://github.com/darwin/plastic](https://github.com/darwin/plastic)

~~~
goldfeld
Wow, cool! Do you plan on making its guts available as a lib to be used under
other frontends? I have a ClojureScript ncurses framework and would like to
attempt a terminal editor,
[https://github.com/goldfeld/i9n](https://github.com/goldfeld/i9n)

~~~
dr_win
The core will be reusable as a javascript library (rendered via react.js). But
you will have to provide keyboard inputs, file I/O and other APIs currently
provided by Atom/Electron/Node.js.

------
WalterGR
How is it home row oriented? (Admittedly, I only used in-browser search for
"home" and found nothing.)

Since moving from the home row has such a _massively destructive_ , 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.)

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.

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.

~~~
eru
> Since moving from the home row has such a massively destructive, 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.)

No love for unAmericans or Dvorak?

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

------
kbenson
I _think_ 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.

------
westoncb
I've spent a lot of time thinking about the fundamentals of code editing after
building this:
[https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be...](https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be&t=1m30s)
.

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: [http://westoncb.blogspot.com/2015/06/why-programming-
languag...](http://westoncb.blogspot.com/2015/06/why-programming-languages-
dont-have.html)

~~~
duncanawoods
Hi - heads-up, your site [http://symbolflux.com](http://symbolflux.com) seems
to be down.

~~~
westoncb
Yep, no money to renew web hosting atm :(

~~~
duncanawoods
Ok. I'll drop you an email and see if I can help.

------
rathereasy
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: [https://youtu.be/w5-g0Hps6bA](https://youtu.be/w5-g0Hps6bA)

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:
[https://youtu.be/vwgvVpCRecE](https://youtu.be/vwgvVpCRecE)

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.

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

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

2) Languages contain syntactic sugar. Trees do not. That syntactic sugar goes
a long ways towards making things easier.

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.

4) Trees follow prefix format. Sometimes infix and postfix styles are much
easier to read.

"someString" capitalize map fn

is much easier to read than

(map (capitalize "some string") fn)

Trees require you to descend to the leaf node and read backwards sometimes.

~~~
vinodkd
#3 is why text still wins. text has high information density, which helps when
you have lots of code to deal with.

That, and the fact that every environment has a text editor - especially
terminal consoles.

You can overcome the second factor, but you cannot overcome the first one that
easily.

------
shaunxcode
Is this the same kent beck who wrote "smalltalk best practice patterns"?
Either way this is a very interesting project and a nice write up!

~~~
KentBeck
Yes

------
vinodkd
Also see [http://concrete-editor.org/](http://concrete-editor.org/) (not my
project, just linking to something I found cool)

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.

------
timmclean
I prototyped almost exactly this a couple years ago:
[https://www.timmclean.net/json-editor/](https://www.timmclean.net/json-
editor/)

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!

~~~
vinodkd
This is not half bad as structural interaction goes. Kudos! It took me a while
to figure out how to add a new node, but once I did find the O command, it all
made sense.

It still feels like a lot of work to get something written since you have to
type "EscOPS<text>EscJT" to add "foo":true, instead of just cursor over to a
place and just type exactly that string. However, I can see how one could get
use to that much as how vim users are used to all those arcane keychords for
basic navigation. Also, there's no reason a command string cannot be made into
a macro.

Do you plan to open source this at all? Seems like a good start for someone to
take and add on to.

Edit: found your github, nm.

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

------
jelder
I've been hoping something like this would come a long. Maybe with enough
positive feedback they'll deign to release it.

------
melling
Didn't Jetbrains build something similar?

~~~
mdaniel
It was mentioned elsewhere in the comments, but I believe you're thinking of
Meta Programming System:
[https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)

I regret that I have not had enough real world experience with MPS to comment
on how it might relate to what Facebook is doing.

But as for real world, a JetBrains employee told me that they wrote YouTrack
([https://youtrack.jetbrains.com](https://youtrack.jetbrains.com)) in MPS,
_presumably_ using an "issue tracker DSL" but he wouldn't elaborate further.

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

Too bad the multi-billion dollar Facebook didn't actually produce any usable
code to benefit the community, for a change.

~~~
skybrian
"Multi-billion" is irrelevant here because most people working for a large
company don't have anywhere near that kind of budget. We're talking about two
programmers who were allowed to work on a research project for a month.

Also, Facebook releases lots of great open source software. Apparently you
haven't heard of React? For more see
[https://code.facebook.com/projects/](https://code.facebook.com/projects/)

------
cryptophreak
I’m not willfully connecting my machine to the facebook.com domain.

