Live data from Hacker News

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

news.ycombinator.com

91–100 of 137 posts

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

#91
post #4

This is not what you're asking for, but I think city as a visual metaphor for certain class of programs could work. Imagine literal factories for manufacturing certain class of objects, highways and roads to represent connections between component buildings, warehouse as databases or storage, office buildings as manager objects, etc and code editing is just moving buildings around (probably hard to do fine grained ed…

I like the idea, but I certainly hope it would be nothing like a real city which corresponds more closely to the worst kind of spaghetti code out there, with tight dependencies between otherwise unrelated communities, too many ways to achieve the same task to list, and so on.

Cities work because they're organic and adaptable. You couldn't plan a city, much less understand all of it.

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

#92

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…

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?

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

#93

If you haven't used Colab/Juypter Notebooks yet, I highly recommend you try it. It's a "notebook" style interface used a lot in data science, and it allows you to run "cells" in arbitrary order if needed. Stylized comments are well supported. The other interesting interface I've come across is https://gibber.cc/ and https://glicol.org/ which are both music coding environments though they have slightly different UI so…

The algorave and live music coding scenes are fun to watch, and no doubt their editors are innovative in ways I'm not aware of. Might investigate. As for REPL-driven development, I agree. A smoother way of moving from REPL to editor would be great. I use ptpython and Emacs in terminals. I could probably get ptpython running in an Emacs buffer, never tried that approach. Ptpython's history makes copy-and-paste into Em…

Have you dabbled in org-babel at all?

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

#94
post #4

This is not what you're asking for, but I think city as a visual metaphor for certain class of programs could work. Imagine literal factories for manufacturing certain class of objects, highways and roads to represent connections between component buildings, warehouse as databases or storage, office buildings as manager objects, etc and code editing is just moving buildings around (probably hard to do fine grained ed…

That sounds a lot like Factorio, a game. It even has simple logic gates that can be generated by verilog or something like it.

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

#96

Earlier quoted context omitted.

> Anything to reduce the friction from thought to working software without having to worry about syntax. The syntax complexity will just be moved into a visual layer, it doesn't disappear. > VR with 3D representations of code as, I dunno, pipes, gears, something like that? Those 3D representations will just generate some code again, adding another layer of complexity to the debugging process?

> The syntax complexity will just be moved into a visual layer, it doesn't disappear. You missed the part where our brain is much better prepared to deal with visual complexity than textual. It's like moving the job to a specialized hardware co-processor. Even if the inherent complexity of the task is the same, the environment would allow to do it way more efficiently. And we could also redesign the languages and IDE…

> You missed the part where our brain is much better prepared to deal with visual complexity than textual.

Citation needed.

Text is also a visual representation of language. If you want symbols instead of letters to represent logic you basically end up with hieroglyph like system, a logographic one.

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

#97

Have you heard of dion? https://media.handmade-seattle.com/dion-systems/ It's still in the category of "inserting text with the keyboard", but the underlying representation of the "program" isn't raw text. The text is just a user interface for a more complicated representation.

I've been thinking about this before that you can do more when you work with the abstract syntax tree instead of the plain text and I was wondering whether someone actually did something with this. It's really cool to see their work. I don't know whether they went that far, because I didn't watch the video on the site completely yet, but when you work with the abstract syntax tree, every change becomes a manipulation…

I think JetBrains have something where you can do something like what you’re looking for. https://www.jetbrains.com/mps/

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

#98
post #86

I came across tylr the other week which looks very interesting. Probably easiest to watch this video[1] first then play with the demo and read the paper [2][3]. [1] https://www.youtube.com/watch?v=00riOfMuaNY [2] https://tylr.fun/ [3] https://tylr.fun/essay

Can I use that in VSCode?

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

#99
post #67

https://gtoolkit.com/ - this is a tool optimized for - as the creators say - "figuring things out", ie. exploration and code reading

Do you know how one would this for Python? Would one use it as a replacement for, say, VSCode, or can it be integrated to an existing IDE?
Post reply on HN