Ask HN: More “experimental” UIs for editing/writing code?
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 ] threadJoystick, 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.
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
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.
Now attach a VR headset and controller. Even people without engineering training could do high level administration or editing.
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/
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.
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.
When you learn to code, you'll have many fine text editors to choose from.
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.
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).
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.
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.
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(
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"/>.
This is Dion: https://dion.systems/gallery.html
(Those are videos)
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 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.
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.
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.
https://enso.org/language
- or Flow-based programming ? --> https://github.com/topics/dataflow-programming
- A code drawn in unit is simply a Directed Graph.
- Programming can be partially performed by Gesture and by Voice.
It reminds me a bit of Muse https://museapp.com/
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.
> 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.
Is there any similar resources for more varied input methods? Like joysticks, custom keyboards, voice or similar?
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.
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.
https://blueprintsfromhell.tumblr.com/
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.
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.
Edit: adjust autocorrect spelling choices
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.
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.)
I am planning to build a tool with this paradigm for creating end to end solutions in my niche. If I ever have time.
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.
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
Same zero innovation area just like browsers.