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

Programmer Tooling Beyond Plain Text

joelburget.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Programmer Tooling Beyond Plain Text

#41

Post by rtpg »

mkramlich wrote: post #32
BoppreH wrote: post #10

I've been working on a Structured Code Editor for a couple of years: https://i.imgur.com/wvcduDk.png (in the picture above "string" is selected, and "find" is slightly highlighted because its on the same level. this helps visualize the tree and plan your movements) It actually started as my final project during undergrad. Here's my 78-page thesis on it (unfortunately Portuguese, but has English pictures): https://pro…

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros…

An advantage of using something that isn't text is that our tooling can also be better. I think we've all had the experience of git diffs being complete messes due to some variables moving around but git matching the wrong parentheses

I agree that with a language like python (or most all languages) syntax doesn't become an issue, but if we can reduce complexity on one part of the editor, maybe we can introduce stronger _general_ refactoring tools (not just language-specific ones).

Anyways I think there's some good research happening in the domain of program editing (light table being one thing, albeit derived from some other tools), because the objective isn't to write hello world quickly, but to be able to quickly and confidently iterate on larger codebases (much like what vim lets you do quickly for simpler formats)

Re: Programmer Tooling Beyond Plain Text

#43

Post by sunnyps »

WalterGR wrote: post #22

With previously working code above and below, I start to declare foo. In the process I introduced unmatched ‘{’; '('; and '"', and am referencing the not yet (fully) declared foo. This is routine editing, but it causes huge problems to tools like * typechecking * go to source * code folding * autocomplete * etc Visual Studio and C# aren't without problems, but they are without this problem. This works fine.[1] I'd be…

It's not a solved problem if your project is gigantic or if you're doing cross-platform development and don't want to or can't use the build system of the IDE or if it's C++.

To me solving the problem has a higher bar - you should be able to open a large project for the first time and have usable intelligent editor support within a second. I'm even okay with the results of autocomplete being incorrect (to a degree) if they are fast.

I think IDEs make the wrong tradeoffs. They require you to use their build system and insist on parsing all the code in your project before providing anything useful. And guess what none of the IDEs that I tried for C++ provide something as basic as a fuzzy file finder by default. Most don't even have plugins for that and those that do have very bad and slow implementations.

For me something like Sublime Text with a few plugins works great. And before anyone goes yada yada about semantic autocompletion and all that - you can get that too at a very cheap cost - look at YouCompleteMe for vim. For project wide searching I find it easier and more reliable to use grep (or git-grep, ag, ST built in search, etc.) than relying on the IDE's find symbol functionality.

Re: Programmer Tooling Beyond Plain Text

#44

Post by westoncb »

I was working on a text-free structural editor a couple of years ago which people seemed to like (and probably now think of as vaporware). I was writing it under kind of ridiculous conditions, though, and needed to take a break. I've moved its project page here recently (with video): http://symbolflux.com/projects/tiledtext

I head a realization a couple weeks ago about how to simplify some core pieces (which were making undo/redo... insane), and started getting back into the code. I wish I could dedicate myself to working on it full-time, but I need to be cautious about coding too much. So, it's either I work a shitty minimum wage kind of job, or don't really do side projects. Thinking of leaving professional software again in order to keep the side projects :/

Re: Programmer Tooling Beyond Plain Text

#45

Post by nightski »

peter-fogg wrote: post #23

OK, let's talk about parsing. The article claims that parsing isn't necessary with structured editing. We're working on some abstract data structure representing our language's syntax. This might be an AST, like any programming language in common use today, or maybe in the future we've thought up some better way to represent programming languages within the compiler/interpreter. Since we're working directly with the…

No. There is a large difference between parsing commands which affect the structure of a program and directly parsing the structure itself. For one, commands that affect the structure in an invalid way can be rejected. Second, commands can be stored so that a history of source code manipulations can be replayed (which while possible via text ala git is very lossy and subject to merge issues - as stated in the article). In addition, commands are limited by context. So when parsing the user's input we now have a limited context to work within greatly improving accuracy and also simplifying the input space of the user.

These are just a few of the reasons...

Re: Programmer Tooling Beyond Plain Text

#47

Post by seanmcdirmid »

BoppreH wrote: post #29
seanmcdirmid wrote: post #28

Earlier quoted context omitted.

> Structured editing is much, much, MUCH better suited for programming than plain text. Syntax preservation and source-display separation are game changers, and they are not the only benefits. You can do a lot of things with a parser and a rich code editor...e.g. http://research.microsoft.com/en-us/projects/liveprogramming... Parsing is just a detail, if you can get it right, you don't necessarily need a structured o…

Interesting research, specially because it has a lower learning curve. I see it as a halfway between fully structured and fully textual. The large screenshot[0] is a textbook example of structured editor, but the cursor moves around as if it was text. It looks like the document is modeled as a combination of complete structures plus a few incomplete pieces of text. That's interesting because you get the benefits of s…

> Also, does erasing the dot after ≱ yield ≥ or ≯?

Yes. Actually, in my newest prototype, the dots disappear and we treat ≱ as having 3 characters (the first is !, the second is >, the third =). Deleting the first character is deleting the ! (you get ≥), or deleting the last character is deleting the = (you get ≯).

Re: Programmer Tooling Beyond Plain Text

#48

Post by unhammer »

BoppreH wrote: post #34
mkramlich wrote: post #32

Earlier quoted context omitted.

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros…

Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the ke…

Isn't d% a more likely vim command?

Although, you'd think vim would have a general "transpose text object" operator. If it were bound to some ŧ, then you could just do %ŧ% (here emulating Emacs' C-M-f C-M-t)

Re: Programmer Tooling Beyond Plain Text

#49

Post by josteink »

WalterGR wrote: post #35
melloclello wrote: post #2

I've long felt that a proper structured editor would work somewhat like a tree editor[1]. Code is trees, right? [1] https://pcmonk.wordpress.com/2014/04/01/why-dont-we-have-a-g... If you had a really good, intuitive tree editor, I would imagine it would be easily adaptable to all kinds of interfaces and scenarios. Mobile, web, VR...

If you had a really good, intuitive tree editor People who write Lisp in Emacs seem to swear by Paredit.[1] I've not used it so I can't respond to either "really good" or "intuitive", but let's see if this works: To the Paredit user who just clicked the comments link followed by Ctrl+F paredit: what do you think of it? [1] http://danmidwood.com/content/2014/11/21/animated-paredit.ht...

Paredit is wonderful and the only way to write lisp.

It let's you treat the code as structures, as trees and work on those directly.

That's all, but it's really really powerful.

Re: Programmer Tooling Beyond Plain Text

#50

Post by titanomachy »

unhammer wrote: post #48
BoppreH wrote: post #34

Earlier quoted context omitted.

Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the ke…

Isn't d% a more likely vim command? Although, you'd think vim would have a general "transpose text object" operator. If it were bound to some ŧ, then you could just do %ŧ% (here emulating Emacs' C-M-f C-M-t)

Thinking structurally, I would use `da(`. Of course, `d%` is less keystrokes.
Post reply on HN