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

Prune: A Tree-Based, Home-Row-Oriented Code Editor

facebook.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#11

Post by 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.

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#13

Post by 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...

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

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#14

Post by LukeHoersten »

daveloyall wrote: post #10

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 More info: http://www.emacswiki.org/emacs/ParEdit

Emacs has structured-Haskell-mode designed after paredit mode as well. (shm they call it)

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#15

Post by LukeHoersten »

tikhonj wrote: post #13

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…

Totally agree. You don't have to build a whole new tool just to try out this new method of editing code. I use both ParEdit and SHM from time to time and they work really well but it's a departure form muscle memory to say the least.

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#16

Post by dwc »

pcmonk wrote: post #7

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

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.

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#17

Post by goldfeld »

dr_win wrote: post #8

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

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

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#18

Post by habitue »

tikhonj wrote: post #13

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…

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

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#19

Post by [deleted] »

dwc wrote: post #16
pcmonk wrote: post #7

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

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.

[deleted]

Re: Prune: A Tree-Based, Home-Row-Oriented Code Editor

#20

Post by 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.

Post reply on HN