Ask HN: More “experimental” UIs for editing/writing code?
101–110 of 137 posts
Re: Ask HN: More “experimental” UIs for editing/writing code?
#102It’s not a very well developed idea, dispute it having floated somewhere in my head for over two decades.
Re: Ask HN: More “experimental” UIs for editing/writing code?
#103https://petersaxton.uk/log/ Week 1 & 2 I mostly introduce the structural editor, later updates have been more about language development
Re: Ask HN: More “experimental” UIs for editing/writing code?
#104Ever since I started learning Borland Delphi as an early teenager I’ve had this idea of an IDE where every function lives as its own entity (maybe like a card) and in the editor is connected to all functions that it call and all functions that call it and I suppose the whole editor must be a giant graph/mind map. It’s not a very well developed idea, dispute it having floated somewhere in my head for over two decades.
Re: Ask HN: More “experimental” UIs for editing/writing code?
#105Cursorless 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?
- 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 a large boost in speed.
- I can add whitespace around function arguments, or empty lines above/below any given line without having to move my cursor there first.
- etc.
Re: Ask HN: More “experimental” UIs for editing/writing code?
#106I haven’t fully wrapped my head around this. It’s a moldable editor where different types of data can each have their own view.
Re: Ask HN: More “experimental” UIs for editing/writing code?
#107This 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?
#108Here's a nice document with many programming interfaces by Johnathan M. Edwards 1948 Plugboards 1949 Keypunch 1963 Teletype 1970 VT05 1980 Symbolic Lisp 1980 Smalltalk 1986 Boxer 1987 Self 1987 HyperCard 1987 Alice Pascal 1991 Visual Basic 1991 AgentSheets 1994 SK8 1996 Squeak/eToys 2001 Eclipse 2003 Flash MX 2005 Scratch … https://docs.google.com/presentation/d/e/2PACX-1vSPuf3eQ2tlC...
Is there any similar resources for more varied input methods? Like joysticks, custom keyboards, voice or similar?
Re: Ask HN: More “experimental” UIs for editing/writing code?
#109This 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.
The charm of a city however, certainly comes from the organic and adaptations its inhabitants make over time.
I'm optimistic that a program's city metaphor has the potential to be just as charming, instead of turning into spaghetti.
Re: Ask HN: More “experimental” UIs for editing/writing code?
#110This 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’s a really neat idea, what better way to intuitively understand what a program is doing than a familiar physical environment in front of you. Reminds me of the esolang Taxi, where you perform computation by giving directions to a taxi driver carrying “passengers” (data) around a city [1] The city metaphor would probably create a whole new genre of software-art too, where you can optimize for beautiful layout/arc…
It'd be great if a program's city metaphor by virtue of the rules (similar to Python's indentation rules) give rise to efficient/beautiful architectures. For example, for obvious reasons, buildings close to each other enjoy in-memory proximity and thus cache locality induced performance improvements.