The evolution of a structural code editor
crowdhailer.me
crowdhailer.me
There're good reasons it hasn't been done more: text is good for troubleshooting, "every program should do one thing well" and maybe preventing lock-in.
But with programming tools reaching maturity, we'll see more of this. Also there's an AI-related aspect: bots can understand structure just fine.
At large, text wins because the job of a program text is to communicate the program to a user in a way that a computer can also be made to use. Things that help include that text can have multiple interpretations and meanings. This is why most variable names are nouns. You can literally "ascii art" parts of code to help convey some ideas.
The most important part of why "text" wins, though, is that it is all visible. Yes it implies some structure underneath that the computer is going to need. The text, though, is fully visible to users. People think they want the ability to "structurally edit," and you can sometimes make that work rather nicely. Most of the time, though, you are working with structures that are not complete. And worse, completing them will not be a process that goes in the same direction as the text. You will have to start a stack in how you are processing things to complete as you go.
I'm torn on the bots comment, as I just don't know. LLMs, arguably, are leaning in on the structure that has been embedded in our symbolic text over many years. The same structure has not necessarily been developed in computer programming texts?
(Also worth paying attention to how most of these goals were pursued with symbolic programming techniques back in the day. LISP, of course, but also term rewriting techniques that used to be rather magical.)
This is very insightful. A program that is being edited passes through all sorts of incomplete states. Non-structured editors will let you do things like paste mismatched braces .. which sometimes you definitely deliberately want to do!
Edit: someone else makes this point at greater length https://news.ycombinator.com/item?id=42612969
SQL is an extreme example of strings parsed to make complex computer behavior. Shell scripting too.
For enforcing complete object correctness and interfaces as they are explicitly designed then low code no code seems like it has a better proposition.
Anyway, maybe structured editors fit a space between dumb strings and pointing and clicking blocks and connectors. I’m all for correct tool for the job and end user. I think that minimizing end user tooling with some LSP go-to definitions and linting in a text editor is my preference. Similar to how FIFA used to be against high tech slow mo replay for soccer matches to make the sport egalitarian / accessible for the whole world I think that analogously programming should focus on the simplicity and portability of authored documents.
It's nearly impossible (if you read the docs) to write something with bad syntax on those machines. Columns are semantic in most of the languages (COBOL, RPG, DDL). When you write a program, if you don't know what you're doing, you can press "F4" and it will show you what each column means and when/how to use it [0]. It's not exactly a structured code editor, but it shares some similar concepts (see the link; you often write code in a "prompt" at the bottom of the screen, and the line won't insert until it's complete, though you can write it by hand if you wish).
All of that said, IBM's old SEU is still vastly inferior to modern text editors and IDEs, mostly because of the limited view window and the lack of syntax highlighting / basic modern features [1].
I think that, especially for enterprise code/development, there are some benefits to structured editing that are worth exploring. Not having a linter shout at a partially-complete line because you paused for a second or two would be nice, as well.
[0]: https://youtu.be/iw_wk5elf3Q?si=m9zVeboTyw0T8_Wu&t=635 [1]: https://youtu.be/Q3hxwcYB1Oo?si=WE9-rFdYo72A5yXz&t=404
Wow. It's amazing to see the beast laid out so clearly before me.
As someone who grew with the mantra "a program is a piece of text", my jaw dropped when I read this post and realized that it was not written in jest. Of course the mantra is still deeply entrenched in my mind, it's too late to remove it now; but I feel as if the world is crumbling around me. What other sacred beliefs will fall? Why doesn't everybody realize that the text file is one of the finest inventions of the third millennium?
Maybe it's just another period in the eternal cycle of fashion trends... programs as free-form text files were an exhilarating liberation from the crufty, fixed-form structures of older languages. Now, we are not only going back to write our code starting at column 4 (like in punched cards), but we still want to add even more structure to it! Maybe in forty years we will go back to free-form text and cherish it again.
Reading the sentence "programs are not text" was the first time I felt old in my life.
For me, json files are also just text files. Or ini files. Or md files.
They do, however, prescribe some structure, or syntax, in them, to be parseable by the interpreter/compiler/whatever. I think this has always been the case.
The command line interface of a language should be really good and one should be able to program without any fancy tooling. The compiler shouldn't offload any responsibility to the editor/lsp.
Programming languages reached maturity 31 years ago, with the approval of X3.226-1994, which specified a language which is at once textual and structured, and easily amenable to structured editing:
(defun square (x)
(* x x))
Structured editing was being performed on teletypes almost 60 years ago: https://en.wikipedia.org/wiki/Interlisp
The future is here; it’s just not evenly distributed.
It’s a super interesting problem space.
I think that could be the key to making structured editing feel less “clunky”.
I've moved on to another (private) repo, but it should be shareable soon.
I'm not a Mathematica user, but isn't their editor also a structural editor? I wonder if anyone has any thoughts about how well that works.
I think this could work reasonably well in Vim. You could have a shortcut in normal mode 'av' (add variable) which would let you create a new variable and possibly set its type and the same every other construct in the language (structs, functions...).
The AI could probably even give you better suggestions in this workflow because it would have a better understanding of what you are trying to do.
If you really think about it, a plugin like this would be a more 'strict' snippets engine. After the LLM revolution we kinda forgot about the idea of using snippets to insert text into our files. But maybe its time to bring this idea back?
I think development tools like this are necessary to expand coding outside of just the desktop experience. For example, I've seen kids program some pretty impressive robotics with just a touchscreen and Blockly.
Also, from a compilers perspective, it feels almost absurd to rely on plaintext. Imagine how much harder code merging is using line diff compared to diffing syntax trees.
Thanks for sharing!
1. If you rearrange your functions you will see a lot of additions and deletions while semantically there is no change in the program. It's just noise.
2. If you rename a variable you don't really have any actual change in places where it is referenced but text diff will again show a lot of noise. But the code references is still the same code.
I didn't say it doesn't. Renaming is a change and you see it but you don't need to see it in every place that refers to that variable. For them there is simply no semantic change they still reference the same variable.
> At least to me whitespace does convey meaning
Can you give an example? If two programs behave exactly the same how whitespace convey a semantic change?
> order of functions
You can see order changes in a structured diff as well if you want but you don't need to hundreds of line of removal and addition like text diff. You would see only the relevant thing which is reordering.
In C, I use FOO() for a macro, foo() for a function like macro and foo () for a function.
Also:
statement1;
statement2;
statement3;
statement4; statement1;
statement2;
statement3;
statement4;
> You can see order changes in a structured diff as well if you want but you don't need to hundreds of line of removal and addition like text diff. You would see only the relevant thing which is reordering.
That is nice then, I thought diffing an AST would lose that ability.
And so did ancient Smalltalks.
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
I still imagine the code would be visually text, but i'm imagining that you'd be able to see a series of nodes in a code flow graph for your current editing context.
I figure AST editing (to some degree) is a generally good thing, but also representing code flow somehow is also a desired thing. It's what i do in my head, so can it be visualized in a beneficial way?
Difficult to say. Keyboard first will also be a challenge as i'll need to have a lot of intelligent alignment and visual compression.
Thanks for the post! Love to see work in this space.
I thought this blog post had an interesting idea too. Basically that a structural editor which truly knew the underlying AST could then alter the visual representation of the code entirely. Eg changing it to look like Python, or whatever insane thing.
Not advocating for that of course, but the idea that the editor could be effectively transpiling the code in real time is an interesting area to explore too. I imagine not for the purpose of "Write Python that becomes Rust" or w/e, but just in general customizing the experience. Perhaps reducing clutter, /shrug
I mean.... ParEdit [1] and ParInfer [2] have been around for a long time now. Structural editing is basically ancient. Lispers have been doing this for a long while, `slurp`ing and `barf`ing their parens.
[1]: https://paredit.org/
This is up there with "everything would be solved with visual programming" and "hey, what if we could put down different syntax on top of the ASTs?". If your mental model is that it must just be because nobody has put any effort into the question, update your model, because in fact tons of effort has been expended and I'd suggest anyone interested in adding to the pile and actually solving the problems (as opposed to playing about, anyone can play with anything they like) is best served by examining the large pile of previous efforts and figuring out what they will do better than before.
Creating a language designed for being manipulated this way is at least a bit more rare than just declaring structural editing is the way forward in a general sense. Still, I'm skeptical. The existence of a textual serialization of programming language concepts is not the problem, nor is the usage of said serialization. Every serious tool already immediately deserializes the text into an AST, and when you really get down to the nitty-gritty of how one represents these things in memory, it is not at all clear that there is necessary a "better" way to serialize these structures, or one that is really very different in the ways that matter. There's a number of well-known (by those who look) pitfalls built into the idea of structural editing and it is not clear at all that the fundamental disadvantages can be overcome. Maybe they can. But the evidence at this point is effectively proof it's going to take more than waving "structural editing!" and some excitement at the problem.
AFAIK, Lisp wasn't created for structural editing, it was just a "happy accident" that it lends itself so well to the technique. Even without the paredit and parinfer plugins, emacs already has good support for structural editing built-in. It reminds me of VIM text objects, but geared directly for Lisp syntax, ie. symbolic expressions.
I imagine you could have an arbitrary "expression" node with N inputs and a textfield, but I've never seen it done and it still feels like a bigger hassle than punching out the expression in a textual language.
I agree with you, which is why mine is more of a text editor augmented by nodes. Notably each node is a variable scope window into text. I'm imaging a single function, more so than individual AST elements. The node can then have multiple inputs and outputs (or relationships of varying types, as i'm imagining) similar to how Blender can have many fields, inputs and outputs.
The variable scoping would mean you can make a single node as large or as small as you need. Including a whole file, or a single expression within a single function, etc. The goal of this would be to visually reduce unrelated clutter, such that relationships should be clear and not dizzying.
I want the nodes to visually represent how i normally work. Which is to say i have a text editor open and often i'm only looking at a single function in the file. Then i jump in and out of the function to related functions. Similarly those are text editor nodes as well, and so the chain continues.
I should stress, i really enjoy my text editor (Helix). I'm trying to add onto that UX ultimately, rather than replace it entirely. Reduce the things i think/hope i don't care about -- ie unrelated functions in a file -- and add things like visual relationships. Imagine an aggressive traditional text editor setting which folds all code you're not using. But with a slightly different representation which hopefully adds to the experience.
Sidenote, another motivation for me is to leave the Terminal. I've been in Terminal for 20 years now but just leaving it is not alone worth it. I want to toy with graphical representations that would be difficult in a Terminal. Something to justify it's existence when compared to something as easy and flexible as the Terminal is.
Is this typo on the web page or in the language?
>type missmatch given: Integer expected: String
or is this an intentional phrasing to match the following text?
The magical ability of plain text is to go back in time and ask "what if I pressed a different button a minute ago/yesterday/last year?". This lets you see and fix mistaken keypresses, and even shapes the kind of mistakes you can make in a moment of confusion into ones that are quickly fixable.
The direct representation of buttons pressed also really helps with teaching/learning: With plain text, for mechanical questions on the level of "What buttons do I press to make a program that looks like that?", the answer is obvious for anyone who knows how to type. Try the editor discussed in the article to appreciate how different answering that question can be in a structural editor. Seeing and explaining how someone got where they did is also straightforward ("you missed a semicolon", "you misspelt a variable name"). Ideally, those are problems that don't happen in a structural editor, but people who press a slightly wrong sequence of buttons will probably still exist.
These arguments get much weaker when you aren't using a physical keyboard; I think this is the reason the article starts by talking about writing programs on a phone and a TV. In those environments structural editing has much more to offer.
That said, the concept of Literate Programming has been one which resonated with me, and which addresses some of the same problems in a fashion which matches the way I work.
Strongly coupling source code to plain text is a lost opportunity to improve tooling.
That's basically what unison does, they store the source code in binary format in an sqlite database.
But I also think that the ux the author presents is undesirable. When writing new code, one must pass through a phase of broken code to reach the working code. I would not want an editor blocking me from typing a word that isn't yet defined but I do want it to notify me instantly that there is a problem.
I also struggled to understand the use case for the mouse based ux. I am typing this comment on an iphone mini and would much rather write raw text on its keyboard than use the clicking interface shown in the fibonacci example.
Almost every visual / structural programming language attempts strands on how you talk about the code, and e-mail people about the code, and write about the code, or even how you efficiently input it.
It's a multi-decade-long problem with many attempts.
I played with Smalltalk, and later Pharo, a bit, but it was years ago. As I recall the editor was always aware of the state of the system. And I think it was at a level beyond what any current IDE can do. While I do not remember if it allowed you to enter invalid code, it was definitely an interesting approach.
So I will be following Eyg for sure.
The problem is that, when you want to make a change to piece of source code you know its current state and you know how you want it to look like at the end. With a normal text editor you will simply make a bunch of changes that turn the text as it into what it should be, it will normally go through a series of invalid states but you don't have to think about what those states will be or care about them. With a structural text editor this is impossible, invalid states can not be represented so when you want to make a change to your source code you don't just care about the beginning and end state, you also want to find a series of valid states that takes you from the beginning to the end where each one can be reached from the previous one with an editor command.
For example, let's say you have a function call:
(afunc 1 2 3)
(if flag (afunc 1 2 3))
1. type "(if flag " before the call
2. type ")" after the call
With a structural text editor, I have to:
1. create a new form before the function
2. type "if flag"
3. select the entire function call
4. cut it
5. paste it as the first branch of the if
1. select the entire function call
2. use a command to create a node around it
3. type "if flag"
So of the benefits listed in the article:
1. "No syntax errors" is actually a major detriment of the structural editing model
2. "Better type information" is a lie, all that the structural text editor guarantees you is that the program is syntactically valid, not that it will pass type checking
3. "No keywords" is a lie, it's only true if you use a new programming language and don't store it on disk as text which opens a whole other can of worms (can't even read source code without a special text editor, won't work with github, won't work with any versioning system, won't work with grep, can't copy paste a chunk of it in an email...)
4. "Rich visualization" is an entirely different story from structural text editing but as far as I know nobody has ever shown visual programming to actually provide any kind of tangible benefit
5. "Reduced complexity" is the one I give them, yes if you are making a structured text editor you don't have to write a fault tolerant parser, it does make your (aka the text editor's implementor) life easier
Fans of structural text editors usually mention that they will unlock "more powerful refactoring tools" but actually all you need for those to be "unlocked" is a dumb parser and an automatic code formatter, like "go fmt". Refactoring a function to be inlined into another is still a difficult operation to implement correctly but it isn't like the difficult part is running a parser on the source code, it's dealing with variable shadowing.
Some of these have existed historically (or even still exist).
Paredit-mode is a structural text editor that saves and loads plain text files, Smalltalk was typically implemented as a dumb text editor but then code was saved as compiled binaries (which meant you couldn't save your functions if they weren't syntactically correct but you could have unsaved syntactically broken functions), Mathematica represents its code in a weird format that might as well be binary but copy/paste converts to plain text, there's one git plugin (don't remember the name right now) that does syntax aware diffs even though git deals with plain text...
This seems sufficiently like the structured programming model (small edits forming a path of "valid" programs from start to finish) that I wonder if something similar to structured programming might be genuinely useful in this niche. That said, these refactors aren't simple atomic tree edits; they're more like a small cluster of tree edits that together preserve meaning. So there's a difference in content, even if the "small edits that form a path through programs with X property" mental model is the same.
1. Position cursor before the call from wherever it is right now (might be quick because your editor already allows some form of structure in it's movement commands: words, parentheses, visual jumps, etc or you might need 10+ presses of the left arrow) 2. Type "(if flag " 3. Position cursor after the call - maybe just a press of "End"/$/shift-A/... 4. Type ")"
Your two ways of structural editing seems to be an artifact of Lisp - I agree that most programming languages have issues when editing structurally - especially when using an abstract/concrete Syntax tree as the structure as compared to a non-syntactic representation (e.g. expression graphs where only types need to match).
So when this weird difference does not exist, you can always use the second strategy you listed. This already includes necessary cursor movements/selections and is one step shorter than the commands necessary for textual editing.
I think that any editor will always have to deal with partial programs - it's just the holes/errors are in different parts. The right UX can make dealing with that possible, just as auto formatting, syntax highlighting, inline type display, etc help somewhat deal with parts already in existing editing systems.
I think there's plenty of ways to make the UX work - for a programming language and ecosystem designed for it. So I think that structural programming should be a complete environment - programming language, editor with a good editing meta-language mapped to keys/auto complete/etc, language server equivalent, structural version control, build system, code sharing/review (diffs!) and legacy interface to textual tools. There'll be a tipping point where one has enough benefits from the structure in each of these to overcome the unavailability of many existing tools like grep/etc. A single structural editor experiment likely isn't at that tipping point unless the UX is really a significant improvement like github.com/cursorless-dev/cursorless is for many folks.
1) place the cursor on the left parenthesis of the form
2) type paredit-wrap-round: M-(
3) type: if flag
Doesn't appear to be overly complex.
1. Place the cursor on the left parenthesis of the form (same as you wrote)
2. C-M-Space to select the form.
3. M-( to surrond with parenthesis.
4. type "if flag" (same as you wrote for #3)
One extra step, but no need for a plugin.
Also, I added a simple "insert-quotes" that I think I mostly copy-pasted from the built-in "insert-parentheses":
(defun insert-quotes (&optional arg)
(interactive "P")
(insert-pair arg ?\" ?\"))
That's M-" .
What truly confuses me is how the PP claims they "went in completely" and "did this for a few months", yet they failed to learn the basics.
I remember dismissing it as a toy back when starting to work professionally with FLTK. Soon I realised I was mistaken; it is excellent to create UI's with for C++/FLKT.
Some code formatters are good and exist for json or edn (extensible data notation) or even full programming languages like smalltalk or even more complex ones like typescript.
In a team it's true that code can be chaotic because not everybody uses a formatter and obviously we all have different coding style, even if the tooling made it more structured.
So yes it would help to enforce more structure in a seamless way so we can focus on the important stuff without creating huge diffs in pull requests.
Note that programs can be syntactically well-formed but ill-typed. For example `let x = true + 1` has valid syntax but produces an "undefined" type for the variable `x`, if the type system does not support type error recovery.
A quote from the great paper from POPL 2024, https://hazel.org/papers/marking-popl24.pdf
> If a type error appears _anywhere_, the program is formally meaningless _everywhere_
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
But there is not much missing and I like the POC!
There are many many benefits to plain text.
But I do wish it was more clear what you have selected, and what things are selectable.
I wonder if this could be generalized to other languages with Tree-Sitter and LSPs. It could be helpful for programmers with accessibilty issues, among many other use cases.
I have wondered many times if some structural editor with a bunch of high-level library methods (Dijkstra's, for instance) would actually give a good/fast experience for most days. I haven't had the time or interest yet to try and build something yet. But perhaps I should.
A few concerns:
* As developers, our 'world' is so defined by text, we textify things that aren't: We write marked up documentation in plain text (HTML, markdown, etc) and we despise using tools like LibreOffice to write that sort of thing, and we even 'draw' helpful graphs in `.dot` files. We do this for a good reason: It 'works' with our other tools. git itself, and the cavalcade of git-understanding frontend version control systems, are excellent at showing you diffs between textual representations. They don't do 'diffs between these 2 png files' or 'diffs between these two .docx files' well or at all.
Hence, these projects either balloon, or need a pragmatic take. Either you staple 'also reinvent git' onto the project (and in passing you are increasing the hurdle to adopt or try out this stuff for any interested folk), or you think about how to adapt the idea to fit existing practices.
In this specific case the latter seems like the obvious answer: The way to store the program is as a file that, if opened in a text editor, looks just like it. But, I _can_ edit files in git and it looks like a text file even if it really isn't; so what happens if I edit an eyg file with a text editor? How 'perfect' must it be? What happens if in hand-editing the file I added some whitespace that shouldn't have been there as per the canonical storage rule?
These are all easily solvable details, of course. But it's where my brain went. I'm pretty sure the correct answer is 'the source file is still text and is still readable; it's just that the language has some extreme style requirements (think about a language that has no line continuation facilities whatsoever, long lines will just have to be long lines, and dictates exactly how many tabs you can insert; indenting with spaces is not allowed at all, that sort of thing). This is fine because the language is meant to be read as plain text but only edited with the structural editor.
* I often try to think how it would be if I was doing my programming work with a structural editor. From time to time I do things that seem blatantly annoying if I only had a structural editor. Where I really _want_ to dip into syntactically utterly invalid gobbledygook because I'm doing some text edits which will get back to valid code but I go through invalid code. For example, block-based copy/pasting (block = multiselect/multicursor). I'm having a hard time seeing how that would work in a structural editor but I use it from time to time. It feels like a structural editor can hopefully come up with alternatives for all the use cases but I'm not sure. Should there instead be a 'fallback' option where your source file turns into raw text mode and your edit functionality is like any plain jane text editor, you do your text-based transformations and then when done exit that mode, at which point the structural editor reparses what you have. I think that's right but it means the language does, actually, need all the bells and whistles after all: A Parser, an AST, good error handling for syntax errors, and so forth.
I recently added an option to my gitconfig to allow diffing .docx files. My ugly 2-minute hack with Git is still miles ahead of the built-in Word history tracking. Ironically, to facilitate the diff, .docx is internally converted to text, once again showing how powerful it is to have a common denominator.
On the topic of diffs, I think we still have not exhausted the full potential of text-based formats. Just because the inputs are text streams, doesn't mean the diff algorithm has to be dumb. As long as it emits readable output, it doesn't matter what it is doing internally (like parsing C code, detecting renames, etc.)
This is such an obvious lie... Of course, even the disastrously bad editors like VSCode or IntelliJ tools understand code to have structure and allow interaction with that structure. Hell, even text editors not intended to deal with code will usually be able to deal with some structure, like identifying words, lines, perhaps even paragraphs and operating on them.
> No syntax errors. Zero time is spent on missing quotes, semi-colons or other details.
Usually paid for by inability to copy and paste chunks of code... not sure if it's worth the price.
> Better type information. Because the program is always in a valid state the type checker can always run and give meaningful feedback.
Why would you want to run typechecker all the time? What's the benefit? I run it when I'm interested in the results... otherwise it's just noise. By the time I'm interested in results, I'd get code in a decent enough shape to compile, so it won't be a problem.
Other known downsides of this approach: having to access the code in places where the editor isn't available, s.a. reading diffs, debugging, running third-party tools unaware of structured format (which, given how our programming practices have developed, will be inconsistent between versions and platforms).
All in all, I've seen these attempts multiple times before, and it always looks like the benefits simply aren't worth the effort. Or, maybe, too many stars need to align in order for this to actually become really useful in the day-to-day programming work, and so it doesn't happen because of some circular dependency where the tools won't be built, until the product is good enough to use, but the product is never good enough to use because there aren't any tools?
I'm curious, what code editor(s) do you hold in high esteem?
Some anti-features that are preferably be missing from good editors: unnecessarily constraining user to the choices the editor designer or the editor administrator deemed necessary. Excluding particular functionality from automation or requiring substantial workarounds in order to automate particular aspects (eg. having functionality associated with a button that can only be clicked by positioning the mouse cursor over it, or, even worse, functionality that is only available through drag-and-drop). Reliance on modal windows. Automatic editing and formatting of editor-related configuration files in a way that doesn't preserve user's edits and formatting.
In other words, it's possible to take a decent editor, like Emacs or Vim and turn it into a bad editor like VSCode or IDEA by doing bad things to it because the base is very extensible. But, in general, excluding the administrative / repackaging component, editors like Emacs or Vim will win in this contest.