(ninth RacketCon): Andrew Blinn – Fructure: A Structured Editing Engine in Racket on HackerTube: recommended by 2 Hacker News commenters across 1 month, 2019–2021.
talk · advanced · evergreen
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.
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”
7 Hacker News comments link this video. Each one links back to its thread.
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
in “MicroBlocks: Scratch and Smalltalk-inspired MCU VM for live embedded programming” · View on HN
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
in “Hazel: A live functional programming environment featuring typed holes” · View on HN
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 )
in “Snap is Scheme disguised as Scratch [pdf]” · View on HN
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
in “Simula: A VR window manager for Linux” · View on HN
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
in “Lisp Programming in Vim with Slimv or Vlime” · View on HN
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
in “How can we develop transformative tools for thought?” · View on HN
> 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
in “How can we develop transformative tools for thought?” · View on HN