Ask HN: More “experimental” UIs for editing/writing code? | Hacker News Reader

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

138 pointscapableweb134 comments

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?

View on HN

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/

I think that what makes Cursorless "really different for editing/writing code" (per OP) is that it is a voice-controlled structure editor focused on maximizing efficiency. Cursorless leverages tree-sitter to maintain an up-to-date syntax tree of your code, and then allows you to manipulate your code using voice commands that target structures like functions, classes, arguments, etc. Cursorless also has an emphasis on composable / chainable commands. For example https://www.youtube.com/watch?v=EwdpPN-21-g . As you become fluent, you'll find that the emphasis on higher level syntactic constructs and chained commands enables you to program faster than you could using a keyboard, without needing to worry about low-level details like cleaning up commas, selecting functions with a mouse, etc.

But as the creator of Cursorless, I'll allow for the possibility that I'm slightly biased

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 wouldn't necessarily say it reduces cognitive load, but I can get things done more quickly.

- 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.

Cool. I mostly wanted confirmation that it’s better and not just a good substitute for disabled folks, RSI, etc.

I’ll check it out. Does it mesh well with other VSCode functionality? I’m just wondering if you can use it in tandem with a normal keyboard.

Not being a VSCode user myself outside of this context I may not have the best experience to answer the first question, but I don't think it tends to conflict with much except perhaps vim keybindings.

As far as using it in tandem with a keyboard, the main issues you might run into are timing. If you happen to be moving the cursor or typing while a voice command is running it could cause issues. You would probably end up having to take a second to pause and wait for the command to finish before starting to use your keyboard. Other than that, you should be able to use the VSCode instance like normal at any point.

This is great. Thanks. It looks like this really shines for moving the cursor around: every important location in the code has a unique name. I wonder if I could port that functionality to emacs. It would take the place of avy (ace jump).

Check out the #cursorless-everywhere channel in the Talon voice slack workspace; people are already working on an emacs port

I'll also add that the cursor movement functionality, while quite useful as you get started, becomes less and less relevant as you get comfortable with the more advanced Cursorless commands for syntax tree manipulation

That ... looks like it would be pretty neat if I could distinguish the colors.

Definitely a consideration. There are ways around that; you can use multiple hat shapes instead of colors, and/or only use white and a couple of shades of grey. I know at least one person that uses it this way.

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

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.

Have you dabbled in org-babel at all?

Code Bubbles: http://cs.brown.edu/~spr/codebubbles/

Patchworks: https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf

CodeRibbon: https://github.com/CodeRibbon/CodeRibbon

Hazel[0] is really fascinating!

"Hazel is a live functional programming environment that is able to typecheck, manipulate, and even run incomplete programs, i.e. programs with holes. There are no meaningless editor states."

It's a programming language and IDE that's fully integrated with the semantics of the language. I saw the demo at Strange Loop in 2019[1], and it was really cool to see the interactive, dialogue-esque development workflow that I love from super dynamic lisps - but working with a strong, statically, dependently typed language. It reminded me of Idris, but even more integrated.

[0]https://hazel.org/ [1]https://www.thestrangeloop.com/2018/hazel-a-live-functional-...

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

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.

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.

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

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(

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"/>.

That's not Dion. It's a plain text language for DSLs.

This is Dion: https://dion.systems/gallery.html

(Those are videos)

I see, thanks. Is there any information about Dion that isn't a video?

Their website is `dion.systems`.

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.

This thought crosses my mind a lot too. When we're working with code, we're shaping information into structures and patterns. And so our brains are tasked with translating those structures and patterns into text, making sure that text is written exactly right, and reconciling the difference in the observed output of structures and patterns with the text we've written. What if we could stay at that higher level of abstraction?

My de facto example of this that I keep coming back to is syntax highlighting. It's immensely useful, and yet once you get used to it, the brain is able to skip the (conscious) step of breaking it down e.g. "this text is green so it means it is a function name, so the next text should be blue because they are function parameters", etc. It's more like "okay, green, blue, bunch of stuff between the braces, checks out". Indentation, squiggly line error highlighting, etc. all serve a similar purpose. They rely on our minds' fundamental ability to recognize visual patterns without having to fully process them through our language centers.

So I feel like there is a huge unexplored space there for more efficient and natural programming. VR with 3D representations of code as, I dunno, pipes, gears, something like that? Function declarations in specific colors and then call sites in mixed colors when one function is called from another? Anything to reduce the friction from thought to working software without having to worry about syntax.

This is all very abstract and I probably haven't explained it well, but it's one of those things I can't shake because I'm fairly sure there's something there.

> 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 IDEs to take advantage and reduce non-inherent complexity as well. See for example the Cursorless demo linked above, where you can target specific bits of code by naming a letter rather than navigating to them with arrow keys or the mouse.

https://m.youtube.com/watch?v=5mAzHGM2M0k

> 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.

Visual representation is not logical, it works according to gestalt principles. [1] Visual improvements would not be used to represent the program logic but secondary notation to improve and accelerate understanding. [2]

The metaphor would be using a graphics card for rendering the scene and the CPU for the game logic. Without a graphic card, your rendering options are extremely limited.

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

[2] https://en.wikipedia.org/wiki/Secondary_notation

> Anything to reduce the friction from thought to working software without having to worry about syntax

I think that the text/notation based representation of programs (or state machines) is the most effective way.

The reason is that it leverages the human ability to use language. I think our intuition for language and thought is much better than our intuition for 2d/3d spaces.

A picture is worth a thousand words, but if you need exact precision, as programs need, no amount of non-text-pictures would give you that flexibility to describe exactly what you want without losing details.

There is a steep learning curve to languages, but once you have learnt the language, these concepts get attached and integrated to your thoughts. This allows you to design increasingly higher levels of abstraction, until you are working with concepts in your current domain.

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

I was just wondering if the youtrack UI is so bad because it was generated from code rather than designed. I guess this is an explanation.

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"

Thanks!

> 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.

Thanks!

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...

Home computers (and, later, certain environments for DOS) used to have you enter programs line by line in this fashion:

  10 PRINT "HELLO, WORLD"
  20 GOTO 10

You would add or edit a line by using appropriate numbering:

  15 PRINT "HELLO EDIT"

And you could get the full program with:

  LIST

Does this count as line editing?

I think you'd call that line... appending? Definitely not line editing though.

There were line editing features in micro BASICs though. Some early versions of Microsoft BASIC let you say EDIT 10 and be taken into an edit mode, where vaguely vi-like, but more perhaps TECO-like, keyboard commands let you change the line by inserting, deleting, swapping, etc. characters.

The Commodore BASICs let you just cursor up to the line on the screen and change it, and when you hit enter the interpreter just read the screen at that line and accepted it as the new line. There were smarts in there to detect wrapped lines and accept the whole thing. Despite being more primitive it was a huge UI win, so GW-BASIC adopted this approach as well.

TIL, thanks!

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.

Here is an editor for C I'm in the process of writing with a Modal, keyboard-only interface. It features a 3 column source code display format which is different from the traditional single column format. Also, there are on-screen controls such as menus, toolbars, navigation windows etc. The entire screen is used to display source code and keystroke sequences are used for navigation. In particular code folding is very efficient. https://github.com/Rohit-Agarwal-Khitchdee/Modal-GUIs

I've defined a couple of source code navigation constructs above the language level that are embedded inside comment blocks.

While I've written this editor for my own use, I've made it available as an open-source repository Github. It is experimental. The source code is well documented and easy to modify for your own purposes.

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?

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.

How different is this from a language server?

So it's Lisp with uglier syntax?

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?

I’m sure a lisp-like frontend could be made for unison.

The syntax looks more like haskell to me.

Light Table [1,2] attracted a lot of attention here [3] several years ago. The author went on to make another system called Eve [4].

1. https://en.wikipedia.org/wiki/Light_Table_(software)

2. https://github.com/LightTable/LightTable

3. https://hn.algolia.com/?q=light+table

4. https://hn.algolia.com/?q=eve+chris+granger

Check out Jonathan Edwards' "Subtext": https://www.subtext-lang.org/

https://en.wikipedia.org/wiki/Subtext_(programming_language)

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.

- 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

Thanks for sharing Liquid Text.

It reminds me a bit of Muse https://museapp.com/

liquidtext seems amazing!

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

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?

I wrote a living document interface. Nowadays it's probably similar to notion.

The idea was you could write code into it and see all the data structures of the code you wrote. There's a screencast and the code is available but broken. It's written in Angular 1. There was a cool feature where you could select different things on the screen for searching for an operation for them to merge them together.

Screenshots of version 1 (Jena fuseki, sparql, d3)

https://camo.githubusercontent.com/3064a94d00812c1373c4eb3b2...

Screenshots of version 2 in this document (angular, couchdb, pouch, paperjs, masonry, ruby, python, javascript) https://github.com/samsquire/liveinterface

Links to screencast https://github.com/samsquire/ideas#4-living-documents

I created a text-free visual programming language where the program is specified using Programming By Demonstration.

It's called BlockStudio (https://www.blockstud.io) and other people have used it to make some nice little games and animations:

https://blockstud.io/profile/15572

Our team is using a homemade time planning tool. In the past it used to be an excel, these days it‘s an app. Each member had two rows (morning/afternoon). Each column is a date. The team filled it out using background colors. Each color represented a category like holidays, ill, onsite etc. One easily gets an overview of the whole team while providing all the details. At some point you run out of colors since the shades are too similar. We added custom patterns with mixed colors for each category.

In text editors we are stuck at text, these days with a few colors. There are barely any shades of color, no background colors or even patterns at all. The maximum is usually a TODO: which gets a yellow background. It think there is still a lot of colors, patterns and shades to explore to create more of an information dense image than a book. Animation is yet another beast.

Another thing missing in todays editors are logical connections. We define methods, but there is no visual hint where they are called from. Files are still displayed as trees instead of networks. Clearly defined interfaces would show up unless we have the classic spaghetti code.

https://futureofcoding.org/catalog/

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.

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.

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

https://gtoolkit.com/

I haven’t fully wrapped my head around this. It’s a moldable editor where different types of data can each have their own view.

I think about this all the time, it seems to primitive to still just be editing text files. Our monitors are much larger and at a higher definition, and capable of advanced 3D effects.

I've been building a strongly typed language and structural editor. The idea is to develop both to get the quickest editing experience. Having a really small language has made it easier for the editor to have a small set of commands for updating the program.

https://petersaxton.uk/log/ Week 1 & 2 I mostly introduce the structural editor, later updates have been more about language development

I have no experience with it but you made me remember Enso (previously known as Luna).

https://enso.org/language

Some good ones pops up in Projectional Programming [1] once in a while. The pinned thread links to the structure-editors github list [2] too.

[1] https://www.reddit.com/r/nosyntax/

[2] https://github.com/yairchu/awesome-structure-editors

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.

Natto.dev is one of my favourites.

Check out the moldable tools idea, e.g. Tudor Girba's https://gtoolkit.com/

Oooh, that's nice. It looks like a good design team took Emacs' org-babel and really polished it.

AnimationCPU is a new live coding platform with code/no-code IDE. This demo video https://vimeo.com/manage/videos/732098541 and some details https://news.ycombinator.com/item?id=32181251

Ever 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.

Isn't that basically a Smalltalk IDE?

I don't know. It sounds amazing though, if it is.

Are there any videos that shows the power of a Smalltalk IDE?

Not sure if I know of any good ones, maybe this one? https://www.youtube.com/watch?v=HOuZyOKa91o

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’ve always thought https://enso.org/ looked cool. It’s a functional language that has both a text representation and a visual representation as a graph that you can edit directly. I still haven’t played with it much though

I've made a UI editor for React that allows you to edit any element visually but commits changes right to your code the same way you'd do it with a code editor.

https://github.com/impulse-oss/impulse

The Sam Text Editor

http://sam.cat-v.org/

There was a recent twitter thread on this. [1]

Check the replies to find people building stuff:

[1] https://twitter.com/threepointone/status/1555851417604300800

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.

https://uprun.github.io/lisperanto/ - an in-browser AST editor with instant evaluation and code on canvas

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.

One alternative interface could be pen and paper. I’ve used it a lot, but mostly when I was learning to program, these days, not so much.

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.

You can write custom python nodes so there's really nothing major missing.

I just recently witnessed a demo of a structured functional language called lamdu.

Not an editor but I've seen people do crazy things on Minecraft.

Gnu ed.

Ed is the standard editor.

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.

Reply on news.ycombinator.com