Live data from Hacker News

Ask HN: More “experimental” UIs for editing/writing code?

news.ycombinator.com

111–120 of 137 posts

Re: Ask HN: More “experimental” UIs for editing/writing code?

#111
Our team is using a homemade time planning tool. In the past it used to be an excel, these days it‘s an app. Each member had two rows (morning/afternoon). Each column is a date. The team filled it out using background colors. Each color represented a category like holidays, ill, onsite etc. One easily gets an overview of the whole team while providing all the details. At some point you run out of colors since the shades are too similar. We added custom patterns with mixed colors for each category.

In text editors we are stuck at text, these days with a few colors. There are barely any shades of color, no background colors or even patterns at all. The maximum is usually a TODO: which gets a yellow background. It think there is still a lot of colors, patterns and shades to explore to create more of an information dense image than a book. Animation is yet another beast.

Another thing missing in todays editors are logical connections. We define methods, but there is no visual hint where they are called from. Files are still displayed as trees instead of networks. Clearly defined interfaces would show up unless we have the classic spaghetti code.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#112
post #88

Earlier quoted context omitted.

I think you'd call that line... appending? Definitely not line editing though.

There were line editing features in micro BASICs though. Some early versions of Microsoft BASIC let you say EDIT 10 and be taken into an edit mode, where vaguely vi-like, but more perhaps TECO-like, keyboard commands let you change the line by inserting, deleting, swapping, etc. characters. The Commodore BASICs let you just cursor up to the line on the screen and change it, and when you hit enter the interpreter just…

TIL, thanks!

Re: Ask HN: More “experimental” UIs for editing/writing code?

#113
post #73

This thought crosses my mind a lot too. When we're working with code, we're shaping information into structures and patterns. And so our brains are tasked with translating those structures and patterns into text, making sure that text is written exactly right, and reconciling the difference in the observed output of structures and patterns with the text we've written. What if we could stay at that higher level of abs…

> Anything to reduce the friction from thought to working software without having to worry about syntax

I think that the text/notation based representation of programs (or state machines) is the most effective way.

The reason is that it leverages the human ability to use language. I think our intuition for language and thought is much better than our intuition for 2d/3d spaces.

A picture is worth a thousand words, but if you need exact precision, as programs need, no amount of non-text-pictures would give you that flexibility to describe exactly what you want without losing details.

There is a steep learning curve to languages, but once you have learnt the language, these concepts get attached and integrated to your thoughts. This allows you to design increasingly higher levels of abstraction, until you are working with concepts in your current domain.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#114

Cursorless is an editor created for editing with voice control. It is built on top of Talon Voice and VSCode. Every token in the file is marked with a "hat," and you can refer to different pieces of your code without having to place your cursor there by stating the color/shape of the hat and the letter that the hat is above. I started using it to help with some RSI, and honestly when I go back to a keyboard to use em…

That ... looks like it would be pretty neat if I could distinguish the colors.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#116
post #68

Earlier quoted context omitted.

The original refactoring browser/editor was https://en.wikipedia.org/wiki/VisualAge it was later Open Sourced as Eclipse but it predates it by over a decade.

I don't think Eclipse is Open Source Visual Age for Java. Both came from IBM but... When the IBM rep cam to our company explaining the change he explained what changed and 3 of the points were why I used VAJ and Eclipse did not have them (at the time 10 years later it nearly had them). VAJ worked with an included JRE that allowed you to edit code as it ran. VAJ included a GUI builder VAJ was organised around code str…

My understanding is the Eclipse codebase is descended from VAJ, not that they were the same product. VAJ had the distinctive VA UI.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#117

Earlier quoted context omitted.

Are you saying that you find Cursorless easier that emacs/evil? If so, can you elaborate on what it is about Cursorless that you find reduces cognitive load?

I wouldn't necessarily say it reduces cognitive load, but I can get things done more quickly. - I can delete a whole line/function/paragraph with one command from anywhere in the viewport. - I can bring a variable name from anywhere in the viewport to anywhere else with one command, and if the name is hard to type quickly or doesn't autocomplete well (perhaps because it is similar to other names in the file) that is…

Cool. I mostly wanted confirmation that it’s better and not just a good substitute for disabled folks, RSI, etc.

I’ll check it out. Does it mesh well with other VSCode functionality? I’m just wondering if you can use it in tandem with a normal keyboard.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#118
post #114

Cursorless is an editor created for editing with voice control. It is built on top of Talon Voice and VSCode. Every token in the file is marked with a "hat," and you can refer to different pieces of your code without having to place your cursor there by stating the color/shape of the hat and the letter that the hat is above. I started using it to help with some RSI, and honestly when I go back to a keyboard to use em…

That ... looks like it would be pretty neat if I could distinguish the colors.

Definitely a consideration. There are ways around that; you can use multiple hat shapes instead of colors, and/or only use white and a couple of shades of grey. I know at least one person that uses it this way.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#119

Earlier quoted context omitted.

I wouldn't necessarily say it reduces cognitive load, but I can get things done more quickly. - I can delete a whole line/function/paragraph with one command from anywhere in the viewport. - I can bring a variable name from anywhere in the viewport to anywhere else with one command, and if the name is hard to type quickly or doesn't autocomplete well (perhaps because it is similar to other names in the file) that is…

Cool. I mostly wanted confirmation that it’s better and not just a good substitute for disabled folks, RSI, etc. I’ll check it out. Does it mesh well with other VSCode functionality? I’m just wondering if you can use it in tandem with a normal keyboard.

Not being a VSCode user myself outside of this context I may not have the best experience to answer the first question, but I don't think it tends to conflict with much except perhaps vim keybindings.

As far as using it in tandem with a keyboard, the main issues you might run into are timing. If you happen to be moving the cursor or typing while a voice command is running it could cause issues. You would probably end up having to take a second to pause and wait for the command to finish before starting to use your keyboard. Other than that, you should be able to use the VSCode instance like normal at any point.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#120
post #15

Earlier quoted context omitted.

If you don't want open source developers to starve, you damn well put your money where your mouth is. High quality open source software is worth paying for. The times when open source software is a niche cottage industry powered by volunteers are long gone. Time is not free, and software does not grow on trees (despite what overprivileged lisp users may claim).

I didn't say it's not worth paying for. I said that if you're getting something in return for your money, then you shouldn't call your payment a donation.

[deleted]
Post reply on HN