(ninth RacketCon): Andrew Blinn – Fructure: A Structured Editing Engine in Racket

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)

> 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'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