5 ms·

Awesome! Glad to see more exploration in this space. I too am exploring this, though i am perhaps making it yet even more complicated. I want to represent relat

Awesome! Glad to see more exploration in this space. I too am exploring this, though i am perhaps making it yet even more complicated. I want to represent relationships between AST nodes in a visual way. Eg, i love Node editors in Blender and if it was given a good keyboard based UX i could imagine editing structural code in it. 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.

unshavedyak 2y ago
Oh, related in this space: https://mbuffett.com/posts/structured-editing-syntax/ https://mbuffett.com/posts/structured-editing-syntax/ 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
Slackwise 2y ago
> Glad to see more exploration in this space. 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/ https://paredit.org/ [2]: https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/
- jerf 2y ago
  I have no problem with anyone jousting with the windmills; I have a problem when they don't realize they are windmills. Hundreds and probably thousands of programmers have taken a crack at this problem. That doesn't prove it's a bad idea but it is effective proof until shown otherwise that if it is a good idea it is not such a good idea that it can instantly catch up to the decades of work in text editing. And the way some people talk about it, it's clear that a lot of programmers think that it should be that good. 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.
  - kagevf 2y ago
    > Creating a language designed for being manipulated this way 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.
alexvitkov 2y ago
My biggest problem with node-based programming interfaces is the absurd number of nodes required for even fairly simple expressions, e.g `b*b-4*a*c` is 9 characters in most textual languages, but it would require 9 nodes in most visual scripting systems. 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.
- narag 2y ago
  Indeed, a hybrid approach seems better.
- unshavedyak 2y ago
  Well to be clear, my model (that i'm trying to make, it doesn't exist yet) is very mixed with traditional text editing. 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.

unshavedyak 2y ago

Oh, related in this space: https://mbuffett.com/posts/structured-editing-syntax/ https://mbuffett.com/posts/structured-editing-syntax/ 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

Slackwise 2y ago

> Glad to see more exploration in this space. 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/ https://paredit.org/ [2]: https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/

jerf 2y ago
I have no problem with anyone jousting with the windmills; I have a problem when they don't realize they are windmills. Hundreds and probably thousands of programmers have taken a crack at this problem. That doesn't prove it's a bad idea but it is effective proof until shown otherwise that if it is a good idea it is not such a good idea that it can instantly catch up to the decades of work in text editing. And the way some people talk about it, it's clear that a lot of programmers think that it should be that good. 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.
- kagevf 2y ago
  > Creating a language designed for being manipulated this way 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.

alexvitkov 2y ago

My biggest problem with node-based programming interfaces is the absurd number of nodes required for even fairly simple expressions, e.g `b*b-4*a*c` is 9 characters in most textual languages, but it would require 9 nodes in most visual scripting systems. 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.

narag 2y ago
Indeed, a hybrid approach seems better.
unshavedyak 2y ago
Well to be clear, my model (that i'm trying to make, it doesn't exist yet) is very mixed with traditional text editing. 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.