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

21–30 of 47 posts

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

#21

Post by abhishivsaxena »

bcheung wrote: post #20

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…

me too!

1) Good ui/ux along with a nice color theme can help a lot.

2) What if it's actually just a lisp variant?

3) Very true.

4) Lisp like macros might help with it?

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

#22

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

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

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

#23

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

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

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.

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

#25

Post by mraison »

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

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"

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

#26

Post by eru »

WalterGR wrote: post #6

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

> 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?

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

#27

Post by vinodkd »

timmclean wrote: post #24

I prototyped almost exactly this a couple years ago: 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!

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

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

#28

Post by vinodkd »

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

There is an augmented programming group that discusses structured editing and alternate program creation environments; maybe that's a place to start?

https://groups.google.com/forum/#!forum/augmented-programmin...

disclaimer: i joined when the group started, but havent been active. i'm perennially interested in the structured editor concept, so cannot resist responding every time it surfaces on HN.

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

#29

Post by vinodkd »

bcheung wrote: post #20

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…

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

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

#30

Post by vinodkd »

Also see 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.

Post reply on HN