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?
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/
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
…
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.
Patchworks: https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf
CodeRibbon: https://github.com/CodeRibbon/CodeRibbon
"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-...
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.
Now attach a VR headset and controller. Even people without engineering training could do high level administration or editing.
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.
I'm not sure anyone's actually using it, but there are some good ideas in there.
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'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...
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'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.
1. https://en.wikipedia.org/wiki/Light_Table_(software)
2. https://github.com/LightTable/LightTable
https://en.wikipedia.org/wiki/Subtext_(programming_language)
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.
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.
- or Flow-based programming ? --> https://github.com/topics/dataflow-programming
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.
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
It's called BlockStudio (https://www.blockstud.io) and other people have used it to make some nice little games and animations:
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.
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).
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.
Edit: adjust autocorrect spelling choices
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.
https://petersaxton.uk/log/ Week 1 & 2 I mostly introduce the structural editor, later updates have been more about language development
It’s not a very well developed idea, dispute it having floated somewhere in my head for over two decades.
Check the replies to find people building stuff:
[1] https://twitter.com/threepointone/status/1555851417604300800
Same zero innovation area just like browsers.
Ed is the standard editor.
When you learn to code, you'll have many fine text editors to choose from.