💾 Archived View for bbs.geminispace.org › s › programming › 22007 captured on 2024-12-17 at 15:09:36. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
The tools for a structure-aware editing have existed for a long time in IDEs and things like tags, cscope and lsps as of late, as well. However, the editors fully commited to this kind of mindset haven't really been done well before. Here, I'll list some of the reasons I myself have found while trying to design one, later abondoning the project.
Also, while I am myself pessimistic of this idea, it would be interesting to hear other perspectives, or inspire somebody to try to come up with better ideas than what I had.
The main idea behind a structure editor is, to make a kind of language for editing, in the vein of vim. The difference is, that language would be concerned with things like function declarations, scopes, expressions, closer to a way a programmer might think rather than a typist. It also, by design, allows you to completely get rid of syntax errors.
Some refactoring actions, such as renaming a symbol, that in a regular editor involve a lot of edits, become as easy as just changing one string: since the every other instance of it is a link, not a copy, they would be renamed automatically.
The problem with this approach is that, in reality, this kind of language is very limiting and there seem to always be corner cases where something that would've been trivial to do in a regular editor requires a whole new construction to be added to the language.
A complex heterogenous data structure like syntax tree just doesn't seem to lend itself to generic, reusable interactions.
There's a lot of overlap between what different programming languages might offer, but there's a lot of difference as well. A structure editor, if it's not specific enough to the patterns that a particular language uses, ends up feeling overly verbose and abstract (that is especially apparent in a naive implementation that just edits the AST). Therefore, you'd need to invest a significant amount of time into language-specific code, even if some things are available generically, which, in turn, makes user's experience less transferable between different languages as well.
Editing any kind of metaprogramming code seems like an especially big problem for a structure editors. Even the lightest structure editor-like systems, like syntax highlighting, can sometimes struggle with it. When the structure of the program isn't known before it's compiled, or even executed, a structure editor can't be relied on.
This last problem seems to me like the most difficult of them. On any project with a big enough scope there is inevitably a point when metaprogramming gets involved. And when the tools that a big project would need much more than a small one, stop working correctly, one might wonder what the point of them even was.
The idea here is to use parts of the structure editing engine in an otherwise regular text editor. This is what most IDEs end up doing. It appears to be the best way of going about it, and it works, but I still wonder about the purely structural approach. There are some things that are only possible with those, like editing non-plaintext files, or easily changing the way a program is presented on screen. Something else that would be interesting to try would be to design a structure editor in tandem with the language and see what kinds of opportunities that would allow.
Nov 21 · 4 weeks ago
🐝 undefined [OP] · Nov 21 at 13:10:
@HanzBrix I'm not really sure what you mean by replacing metaprogramming with microservices, could you elaborate on that?
Why would one want to 'avoid metaprogramming'? It's by far the best part, and IMHO lack of it makes languages wimpy.
As a sometimes Lisp programmer who recognizes that the point of Lisp _is_ metaprogramming, I don't see how calling a procedure locally or worse yet, marshaling across some boundary, is even remotely comparable to metaprogramming. We must be using different definitions...
However, having tried and failing to make a structure editor for CL a few different ways, I agree that it's metaprogramming in Lisp makes it extremely hard to figure out the bindings. Because macros can inject symbols into the middle of code, a superpower.
Emacs, much as I don't really like it, with some extensions, does make a decent semistructured environment, mostly due to the mostly uniform usage and semantics of parentheses in Lisp.
Read "let over lambda" - a few chapters are online and there are pdfs floating around. It has changed my life.
🐝 undefined [OP] · Nov 22 at 08:24:
Yeah, lisp is really the best case scenario for these kind of things since the syntax is just a direct representation of the ast. Though that simplicity comes with restrictions on that very ast: one of the reasons you don't have explicit typing in lisp, for example, is not that you can't do it, it's that it would be a pain to write and deal with so people just through inertia end up rolling with a worse system. And, as you've said, the macros break that uniformity anyway.