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

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

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 137 posts

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

#51

Post by Kerrick »

themodelplumber wrote: post #2

I like it... Joystick, pedals, rudder controls, driving a constantly-forking code prediction interface on screen which is helping determine your next line of code based on where you drive or fly. Thinking about PilotWings, where you have targets, but you can choose between them. Each drive or flight is a context, IOW the area inside the brackets / indentations in your editor. Switch contexts very, very fast using som…

> Bonus, attach a big knob somewhere, like on the joystick, for timeline control, which would be like undo / history. What do they call this thing on old video editors? Seeker? Spinner? I forgot.

Not just old video editors, my USB-C video editing keyboard [0] has one too! The marketing materials call it a "search dial" but I'm also used to hearing it called a "jogger." Wikipedia says it can also be called jog dial, jog wheel, shuttle dial, or shuttle wheel.

[0]: https://www.blackmagicdesign.com/products/davinciresolve/key...

[1]: https://en.wikipedia.org/wiki/Jog_dial

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

#54

Post by bgoated01 »

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 emacs evil mode it feels awkward compared to cursorless (other than the fact that it allows me to get out of VSCode, but that's a personal preference...).

This tutorial video gives a short taste of what cursorless is like: https://www.youtube.com/watch?v=h6lM68jU2iI And here is a link to the documentation: https://www.cursorless.org/docs/

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

#55

Post by mdaniel »

cloudmike wrote: post #46

JetBrains MPS [0] is worth a look for inspiration. Like some of the other projects mentioned here, it's an editor on top of an Abstract Syntax Tree. You can use it to make DSLs that have different UI/UX projections. I'm not sure anyone's actually using it, but there are some good ideas in there. [0] https://www.jetbrains.com/mps/

> I'm not sure anyone's actually using it, but there are some good ideas in there.

I guess it's kind of cheating, but they wrote YouTrack in MPS; they used to cite that in the footer, but I guess it was removed cause it was an implementation detail

I reached out to them to ask "what does that mean, written in MPS?" and they said they had a DSL for issue tracking that essentially generated executable YouTrack builds

Interestingly, Workday has a repo for MPS code reviews, although stale: https://github.com/Workday/mps-code-reviewer#readme

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

#57

Post by ilaksh »

mentos wrote: post #25

Check out Unreal Engine visual scripting using blueprints

Unreal Engine Blueprints are probably the leading edge of practical software engineering right now.

One of the core problems with programming is that anything that replaces complex colorful text editing is subconsciously attributed to being for users or beginners and therefore programmers do not want to be associated with it.

This is the main thing holding back software engineering -- most programmers refuse to use these types of tools for fear of looking like users.

And actually it's been like that for years. Probably the earliest example is SmallTalk. Then after that Visual Basic.

Again this is subconscious for most people (I am a programmer myself and also feel the peer pressure to avoid using user-like tools).

Of course at the bottom layer of Blueprints is adding new components with code and this is where the programming effort should be going. Again to some extent that is happening with game programming and Unreal Engine now.

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

#58

Post by ilaksh »

youamericanloo wrote: post #33

how far away the Blender Node Editor from being full fledged coding UI? is that easy to make it?

When I saw what was possible with Geometry Nodes, that pretty much made up my mind that node-based editing was the future of programming.

I am planning to build a tool with this paradigm for creating end to end solutions in my niche. If I ever have time.

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

#60

Post by marttt »

Not exactly "experimental", considering the Unix heritage, but -- line editors.

"I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing." -- Ken Thompson, on the superiority of ed to visual editors. Summarized by Peter Salus in A Quarter Century of UNIX (Addison-Wesley, 1994).

Definitely a blast from the past, but I do think line editors may force one to write simpler programs -- or to think in smaller chunks, as opposed to (doom)scrolling or moving about incrementally on a large screen. Who knows, maybe the line editing approach is making a comeback of sorts, with people figuring out how to write code using tablets, smartphones, RasPi-based low-powered devices, etc. Maybe we will start re-thinking the (possible) mental benefits of smaller screens / viewing less lines of text or code at a time.

Rob Pike's sam editor has an interesting command language. You're not limited to thinking in "lines" as in ed or sed; rather, the whole file is a giant string that you manipulate using regular expressions, external pipes, etc: http://doc.cat-v.org/bell_labs/sam_lang_tutorial/sam_tut.pdf

In the light of the OP's question, I suppose Pike's "structural regular expressions" are the keyword here (explained in the above linked paper). It is a paradigm worth pointing out; also used later in screen-oriented editors like vis.

sam's predecessor, qed, is also interesting, extremely powerful, but it seems to have a much steeper learning curve. I have used sam quite a bit, but not qed. https://github.com/phonologus/QED/raw/master/doc/qed-tutoria...

Post reply on HN