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

138 points by capableweb ↗ HN
There is a bunch of editors with the traditional model of inserting text with the keyboard, arrows move the cursor around, you click around in menus/using hotkeys to perform actions (Visual Studio Code, Atom, Eclipse). Then there is the "modal" editors that have different modes where you can switch between for example "editing" or "movement" modes, and what your keyboard controls depends on the mode you're in (editors like Vim). Otherwise there is also very interactive and extensible editors, where eval basically lives within/together with the editor (Emacs, LightTable)

Otherwise, most editors fit in somewhere along those lines.

But what other editors is there out there that have something really different for editing/writing code? Things that come to mind is "editors" like Scratch where you aren't really "editing" code with your keyboard, but moving things around instead. Or, if I imagine I'd create a editor for programming controlled by a joystick, what kind of UI and UX would that editor have?

136 comments

[ 2.9 ms ] story [ 212 ms ] thread
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 something like even holding down a joystick button and moving the joystick, for example. So you'd have all these environments to fly in, and they could even be generative, unfolding as the code characteristics specialize.

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.

But this is just using one metaphor, in a very on-the-nose sort of way. I'm sure there are tons of different ways to go...

...like sometimes I wish I had a foot control that would recognize the cadence of my feet moving and use that for workspace (mind) suggestion, direction, and control. Ah well, maybe in the future.

Interesting q! No matter what you do, it'd suck in some ways, but it would also have some advantage, some unique thing, and IMO that's the really interesting part. Like maybe the joystick tool I described would be best for prototyping or scaffolding or who knows what.

> 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

There's definitely a world of no-code/low-code platforms, and if you're working purely with data then it might be effective. Node-based programming is readily available in certain other fields as well (Blender does this for shader programming, as do some game engines).

As for "real world" proliferation of these tools, I'm not sure I'd get my hopes up. Compiling code is ultimately about moving things from one text format to another, so having direct control over your input/output is integral to working quickly. One might even suggest that having so many keys on a modern keyboard contributes to how much entropy the average programmer can generate in a short period of time.

I think the real boon is going to be more visual, interactive debugging going forward. Modern resources like LLVM seem underutilized to me, and as we improve LSP support for IDEs we're going to end up with really robust tooling. We're headed towards a paradigm shift in programming, with safer abstractions and more opinionated syntax. These are good changes, but I think our tooling will largely adapt around those concepts rather than WYSIWYG/drag-and-drop editors.

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 editing, as you'll need metaphor or abstraction at a different level). Vehicles are literally rpc calls or data packets. If something's breaking, it can be depicted as traffic jams or accidents or billowing smoke from a building.

Now attach a VR headset and controller. Even people without engineering training could do high level administration or editing.

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/architecture as well as efficiency.

[1] https://bigzaphod.github.io/Taxi/

This is really neat. I like your thinking that it could create a whole genre of software-art. I see it as being very plausible as I'm sure engineers worth their salt have seen poetic charm or elegance in expression of some of their codes.

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.

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.

City can be planned and for them to be efficient, has to be planned. That's why we have urban planners.

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.

That sounds a lot like Factorio, a game. It even has simple logic gates that can be generated by verilog or something like it.
Yeah I've heard of Factorio, but never played it. When you zoom out of a Factorio game you can certainly see some large scale repeating patterns, and how things are shuttled around, which is really neat. Like how when we move things around and step back a little we gain a different perspective or deeper insight into something, I hope this city metaphor could do the same for computer programs.
I don’t know that this is exactly what you mean, but games that come with editors often push the boundaries here a bit because their domain is limited and their audience is not (initially) expert. The Warcraft III editor was essentially spitting out Scripting engine functions under the hood, but the UI presented it much more approachably. I am sure modern equivalents do this even better, but I remember being impressed by that one back in the day.
I loved the Wc3 editor as a kid, reversing obfuscated JASS from all the protected maps to try and learn stuff was like IDA Pro to 9 y/o me.
Those who cannot form a complete sentence resort to grunting and body language.

When you learn to code, you'll have many fine text editors to choose from.

I’d argue that dance is at the very least able to express a _different_ set of concepts than language, often times more directly. Example: intimacy of dancing with a romantic partner offers a different and valuable form of expression than verbalizing the emotions.

Formal language is certainly the most effective mode of communication for some things, but don’t discredit the value of other forms.

Also, this comment seems to discount the spirit of the post without offering any real reasons why.

I've been struggling with what a touch based IDE for my galaxy tab4. Right now I'm thinking about showing a drawer with token suggestions written on color coded chips. Right now I'm struggling with packing an LSP into an Android app.
Labview (1986) and Simulink (1990 or thereabouts) for graphical dataflow programming. For oss and IoT, node-red looks nice but I haven’t used it.

Notebook interfaces - Mathematica has had one forever (1988) and still leads. For oss, everyone seems to like jupyter more than I do.

For low-code/no-code rdbms CRUD prototyping, Microsoft Access (1992).

I would donate a hundred dollar a year recurring for a non-copyleft, open source, production quality simulink with full two-way Verilog/VHDL code generation and import support.
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.
(comment deleted)
I agree with you, but nothing you said precludes copyleft.
I think lisp users are more for code growing from lists, not trees
In the Smug Lisp Weenie hymn book, it is written

But I think that why only God can make a tree.

For God wrote in Lisp code when he filled the leaves with green.

The fractal flowers and recursive roots:

Also in SICP, trees are all made in lisp.

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 had an idea like this forever.... they brilliantly handled the UI in a way that I never could resolve successfully. WOW

Watching more, and reading more, to find out they abandoned the idea..... makes me think of Charles Babbage moving on to the Analytical Engine before getting the Difference Engine completed. 8(

Their website is `dion.systems`.
https://github.com/dion-systems/metadesk seems to be the repo for their prototype.

It seems like it's vaguely similar to SGML but with small but significant differences: instead of <a>blah blah</a> you say a: "blah blah", the node labels can be user data instead of just structure, attribute values are full subtrees instead of just strings, and attributes syntactically precede the node, so you say @foo(bar) baz instead of <baz foo="bar"/>.

The makers of Dion now work at Epic. My guess is they're contributing to Verse [0], a new programming language (environment?) being worked on at Epic, which could be of interest to people in this thread.

Verse is believed to include ideas from SkookumScript, which Epic acquired [1], and Simon Peyton Jones, a main contributor to Haskell [2].

[0] https://twitter.com/saji8k/status/1339709691564179464?s=20

[1] https://skookumscript.com/blog/2019/01-23-epic-aquires-agog/

[2] https://discourse.haskell.org/t/an-epic-future-for-spj/3573

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 on that syntax tree. When you think about source control, you can use that concept in there too and store the changes on the syntax tree instead of individual edits. And when you do that, you would get a lot smarter merging, rebasing and conflict resolving.

For example, suppose you have a variable and branch 1 renames that variable and branch 2 introduces a new use of the variable. If you merge branch 1 and 2, or you rebase branch 1 on top of branch 2, you will not get a conflict, but the code will be broken. If you work based on the abstract syntax tree, the merge would automatically do the correct thing.

Another example would be that branch 1 renames the variable to x and branch 2 renames it to y. In that case, you would get a conflict upon merge, but not upon rebase. (for rebase: last committer wins) In the case of the merge, the system would know that the conflict is the rename of a variable to 2 different names, and the user would be able to decide on which name must be used.

I think it's really an idea worth exploring further and could have a big impact on the quality of code and on the efficiency when working in teams.

That's the idea, but I'm not sure about the AST - that is usually too low level for this kind of reasoning. What you really want for this is similar to reflection types in Java.
Experimental UIs for editing/writing code that I would love to see:

1. Highlight code interrelations. Example: click in a function, and the UI displays related code, along with indicators of the timing of relation (e.g. caller vs. callee), type of relation (e.g. override v. delegate v. strategy), strength of relation (e.g. 80% of the time function "f" is called, then function "g" is called), etc.

2. Collaborate on code reviews. Example: when I do a pull request, then I want to see my team's comments within my typical editor, within my real source code, rather than in some project management tool or some git hosting web page.

3. Make it much easier to write good documentation by automating feedback. Example: when anyone in the world uses my open source, and it doesn't work the way it's documented, then make it easy for the user to provide diagnostics directly to the section of code that's having the issue, suitable for triage by me.

> I want to see my team's comments within my typical editor

ahh, I remember looking at some old code that was mostly casual email-like threaded discussion between developers as comments. It explained the why of things and one could immediately start working on suggestions. It also preserved the mood. Even without changing anything one could drop a few lines and say hi 500 years later. Explain how we do such things nowadays and you have a contribution.

I just recently witnessed a demo of a structured functional language called lamdu.
- like https://www.liquidtext.net/ for program codes ?

- or Flow-based programming ? --> https://github.com/topics/dataflow-programming

unit: Next Generation Visual Programming Platform: https://github.com/samuelmtimbo/unit

- A code drawn in unit is simply a Directed Graph.

- Programming can be partially performed by Gesture and by Voice.

This makes me want data gloves
liquidtext seems amazing!
Have you heard of the Unison Codebase Manager (ucm)? In Unison (https://www.unison-lang.org/) all code is stored as its AST and then you can 'chat' with ucm asking it for specific type signatures for example. Also the text you write as code really is just an intermediate representation and theoretically ucm could give you all sorts of different views on your code.
So it's Lisp with uglier syntax?
I’m sure a lisp-like frontend could be made for unison.
in lisp, you don't know what a given symbol means out of context (i.e. imports/macros in the environment). in unison, all functions are content-addressed so you can literally send code over the wire and dependencies are automatically resolved. it's a really cool system!
Sounds interesting, but considering it is content addressed, I think by sending code over the wire you are also sending its dependencies as well? Otherwise the recipient can't figure out the dependencies when they encounter hash mismatch (assuming some dependencies aren't in the web). If dependencies are sent as well, how difference is this from the lock file approach used by other languages?
How different is this from a language server?
Here'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...
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 structure and not files e.g. you chose packages and classes and methods and not by files.

VAJ was based on the VA Smalltalk environment.

From that Wikipedia link:

> VisualAge for Java is based on an extended Smalltalk virtual machine which executes both Smalltalk and Java byte codes. Java natives were actually implemented in Smalltalk.[6]

> VisualAge Micro Edition, which supports development of embedded Java applications and cross system development, is a reimplementation of the IDE in Java. This version of VisualAge morphed into the Eclipse Framework.

My understanding is the Eclipse codebase is descended from VAJ, not that they were the same product. VAJ had the distinctive VA UI.
While interesting (thanks a lot for sharing this great resource), it seems to mainly focus on just the UX/UI aspects, while ignoring the input method, they all depend on mouse and/or keyboard.

Is there any similar resources for more varied input methods? Like joysticks, custom keyboards, voice or similar?

From the top of my head, I've seen:

    piano-like single hand keyboards 
https://en.wikipedia.org/wiki/Chorded_keyboard

    light-pen, pen-to-text
    foot pedals
    keyboards with two wheels
    text-to-speech (os native)
    gloves and 2D mocap-like cam capture of sign language
    Neuralink.com
I would love to see a demo of SK8. I've never been able to get it to work in any of the classic mac emulators. If anyone out there has experience with this I think the community would benefit from some videos
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.

After experiencing xcode and the mix of gui and code needed to build iOS apps, I realized that having mixed medium makes it hard to figure out how to do something if you haven’t done it before and need examples.

Using code alone allows for fast productivity because you can easily search and replace where needed. If you need to find out how to do something, you search the web and see examples. So your productivity speeds up substantially because you have all components in front of you to give you all necessary context at once. In XCode if there is something that requires a gui interaction to work, there are idiosyncrasies: some drag and drop needed or some deeply nested value in some third priority field that you don’t know about and you’re banging your head against a wall for each piece of functionality. Code puts everything on the same visibility level reachable through search (like a hash table). Gui alone also forces you to explore all fields and then experiment. But both mixed is hard.

BPs are a weird case, its decent UX and good accessibility tricks a fair few non-programmers into a lot of subtle footguns, and sometimes in the pursuit of avoiding writing a few lines of code they will opt to handicap themselves with spaghetti monsters.

https://blueprintsfromhell.tumblr.com/

I one time did a project entirely in notepad. Not notepad++. But the standard notepad that comes with Windows. It was a time when I got tired of frameworks and IDE's that come and go and try to offer things more conveniently. Again having to learn about some new kid on the block. Having to depend on 3rd parties. I wanted everything to be vanilla.

What's interesting is how this forces you to think carefully about structuring your files, folders and code. It also allows you to leverage the Windows files explorer and have your code opened in multiple windows.

I'm now using VS Code. I hate how the file explorer jumps around when closing a tab (because it tries to select whatever other tab becomes visible). VS Code also doesn't allow me to easily open my files in multiple windows. Meanwhile we have browsers that allow us to freely open windows or tabs.

This setting disables the explorer jumping:

  "explorer.autoReveal": false
And here are some settings you can play with to get that window/instance behaviour under control (default values shown here):

  "window.openFilesInNewWindow": "off",
  "window.openFoldersInNewWindow": "default",
  "window.openWithoutArgumentsInNewWindow": "off",
  "window.restoreWindows": "all",
  "security.workspace.trust.untrustedFiles": "prompt"
> I'm now using VS Code. I hate how the file explorer jumps around when closing a tab (because it tries to select whatever other tab becomes visible). VS Code also doesn't allow me to easily open my files in multiple windows. Meanwhile we have browsers that allow us to freely open windows or tabs.

I use VSCode with the Vim plugin (it's not perfect: browsing undo/redo tree can lose changes, opening new tabs with `tabe` doesn't work correctly, etc), but on a widescreen monitor, I use `:vsplit` and `:split` often, and this allows me to view the code in 4 to 6 different files, aiwth all of them on the same screen at once.

I recently discovered the Apple Numbers formula editor UI. It’s surprisingly minimal and nice, it does a good job blending text editing and visual blocks. It’s somewhat reminiscent of scratch or blockly IMO.

Edit: adjust autocorrect spelling choices

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 are both worth exploring to get a sense. What I imagine is an extension of their approach to make going from a (Python) REPL to working code more seamless. My workflow is often play in a REPL until I get it working, and then try and reconstruct the right order of code back in an editor. There's got to be a better way of going from REPL to code than that, but I've not found it yet.

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 Emacs fine, but it's all a bit clunky. Variables, imports, etc all need to be fiddled with. (Separate gripe: ptpython needs restarting if changes are applied to an imported file.)

Most lisps that leverage repl-driven development also have repl integration in the editor itself. So for example, I write my Clojure code with vim as normal, and when I want to run a snippet of code, I highlight what I want to run and execute that snippet in the editor, that communicates with the running repl instance and displays the result in my editor. This way, when I'm done, I simple save the file that has all the code i've evaluated in it already.
how far away the Blender Node Editor from being full fledged coding UI? is that easy to make it?
You can write custom python nodes so there's really nothing major missing.
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.

I saw this talk, Stop Drawing Dead Fish by Brett Victor, a while back. While I don't think it's the tool you're looking for, he does a great job showing why we may want better tools than we have currently and what they might look like. https://vimeo.com/64895205/description
plan9's ACME is interesting how its mostly traditional except for both the mouse-chords and the part that its also a shell. also a window manager. and a file manager.

at one point there was plans to add graphics capabilities to truly turn it into a window manager but well, those never came to be.

It's not general purpose, but colorforth has a really weird and different editor. Coloring words "types" the word (definition label, compiled, immediate, comment, etc), which allows the language and compiler to be dead simple. It really makes me wonder why modern languages aren't designed with IDEs in mind - instead of loading the syntax with complexity, separate it out into the fancy editor layer! Color/text formatting is probably not the best paradigm, but the potential of editor-first language design hasn't really been explored anywhere near as far as it deserves.

As far as conventional editors go, I'm a big fan of vis. Multiple cursors, structural regex, and vi keybindings are just too nice to give up.

https://github.com/martanne/vis

Not an editor but I've seen people do crazy things on Minecraft.
Nothing new in the past 20 years, everyone is copying someone else and doing minimal changes and sell it as "NEW" and "REVOLUTIONARY" editor.

Same zero innovation area just like browsers.