10K views · Jul 19, 2019 · 32:18 · 2 HN recommenders · 7 mentions · discussed 2019–2021
A RacketCon talk presenting Fructure, a prototype extensible structured editing engine in Racket. Language providers define syntactic forms and refactorings as rewrite rules, and editing operates on program structure rather than on text.
Why Hacker News points people here: Cited as a leading example of structural editing whenever threads discuss alternatives to text-based code editors.
“Andrew Blinn gave a neat talk[1] pertaining to structured editing at Racketcon”HN comment, 2020
“Fructure is an example which looked promising!”
Keyboard-driven structure editor keeping code syntactically correct.
I've seen a few attempts at "structure editors" which are keyboard driven but limit what you can type so it's always syntactically correct. Fructure is an example which looked promising! this video
“Andrew Blinn gave a neat talk[1] pertaining to structured editing at Racketcon”
Talk on structured editing crediting Hazel.
For folks interested in this sort of thing, Andrew Blinn gave a neat talk[1] pertaining to structured editing at Racketcon, which credits Cyrus’ work with Hazel. [1] this video
“I have a talk about it here if anyone is interested”
Commenter's own talk on a structured editor.
I'm currently working on a structured editor which is at its core a customizable rewriting engine; you specify a grammar, and essentially all editor actions are rewrites on that grammar. My current target grammars are for simple LISPy languages because of the simplicity, but my original (and eventual) goal was/is as a tool for exploratory mathematics. I've always felt mathematical manipulation as more of tactile, synesthetic phenomena than a verbal/linguistic one; I feel like the current state of haptic input is not quite up to reifying this yet, though it is improving very rapidly these days! So I'm trying to tackle some of the software side, and seeing what can be done towards this goal with extant input devices. What I've done is pretty rudimentary so far, but I have a talk about it here if anyone is interested: this video
Example of structure editor.
> I still think excel is the leader in this category. Yes, definitely. The "reactive functional" programming paradigm of the spreadsheet is radically more understandable for end users than the imperative, as it doesn't require keeping a mental model of state changes in memory. Fortunately, React has popularized this reactive functional paradigm and it is no longer confined to spreadsheets. > I’m thinking the same elements presented in an environment perhaps more like Scratch could work An approach of visual building blocks could help for learning, though Scratch is imperative so it has all the trappings that make a language hard to learn for non-programmers, plus all the inconveniences of editing a visual language (much more cumbersome than editing text). I'd rather have a "structure editor"[1] for editing a textual language (like the spreadsheet, but with a tree representation instead of a grid one), which added enhanced visual representations over the base tree. You know, like the IDEs developers use, but with a functional reactive language that mixed code and data, like the spreadsheet does. [1] this video
“I still have hope for structural editing”
Structural editing as alternative to Vim.
In my mind the main reason why Vim still has relevance today is for seat-of-your-pants SSH'ing, which admittedly shouldn't be done but it still is. Outside of that... I still have hope for structural editing but I don't see Vim as the innovator in that space anymore. this video
Example of structural editing.
I'm not sure I agree with the parent, but to give an example for a non-rectangular UI for manipulating (programming) text: Combine structural editing[1] overlaid on some kind of 3d graph that shows how your entire codebase fits together. [1] this video
“my own efforts in this space (a structured editor in racket)”
Commenter's own racket structured editor.
using a lisp here simplifies things from implementation and interaction model perspectives. you already have a simple, canonical AST out of the box, which in-principle suffices to support the entire language, not just a toy version. so it makes sense lisps are attractive targets for getting something rolling in this space, though it's certainly debatable whether it's long-term the best choice. (my own efforts in this space (a structured editor in racket), which i was able to get going as a novice programmer: this video )
