What does HackerNews think of fructure?
a structured interaction engine 🗜️ ⚗️
not totally wrong but i did write this https://github.com/disconcision/fructure with ~2 years programming experience. implementation features some nice simple define-syntax-rule macros which i maybe never wouldve managed with defmacro
You might be on to something with the “apply” idea. What if there was a split screen where you could see both code/operations and data and could mix them together with all the transparency of a spreadsheet? macros would just exploit code as data?
For a tangent that might spark interesting ideas, check out this structure editor project in Racket (a lisp) https://github.com/disconcision/fructure
https://interlisp.org/ shouldn't be hard
> more
https://github.com/disconcision/fructure
Partly inspired by hazel, less active but probably a more broadly appealing language.
Fructure might be nice on a phone! Currently makes heavy use of keyboard shortcuts but I bet it could be adapted to a touchscreen.
Formatting is not a major part of the result, it is just a nice side effect; I didn't mean to give it so much attention. I will not say, however, that formatting is a non-issue. It isn't an important issue, but it is one that a disappointing number of man-hours have been spent thinking about. Just look at all the comments and controversy on this ticket about zig not supporting tabs: https://github.com/ziglang/zig/issues/544. Consider how much time has been spent making auto-formatters, and making them preserve things like comment alignment. There are 'less mature teams'; what will you do for them?
> I can type characters much faster than I can drag a mouse, so I’m not seeing any increase in productivity.
Like I said, I don't want to rewrite everything in scratch. I have no intention for the future to be anything but keyboard-driven; an editor which is aware of tokens and syntax trees will be better able to facilitate editing, no matter what your inputs. Consider fructure[1], which is not dissimilar to what I propose. I don't think it uses the mouse at all.
I wanted the basic elements of the interface to be at a higher level than individual characters. The nested squares style rendering is highlighting grammatical structures in the language—not to teach syntax, but just to indicate where an interactable UI element is, the same way you have rectangular bounds around a button etc.
My motivation for this was to make it easier to manipulate code with lower-precision input devices (e.g. the microsoft kinect / leap motion), but I think there is general interest because a lot of the people writing these editors start from the premise that interacting with the AST directly (as opposed to character sequence) opens up doors, and nested squares is just kinda the most natural/obvious way of rendering an AST. It's also a more natural pairing with the input style of many of these interfaces (e.g. Lamdu[2] or Fructure[3]) which also operate at a higher level than character sequences.
The alternate rendering in itself isn't world-changing, it's the underlying change to directly manipulating a model that then gets rendered (as opposed to parsing the interface—i.e. character sequences—in order to arrive at the model) that's important.
(And even it probably isn't the most important revision to programming tools in general—but that doesn't make it not worth working on if someone's interest is in that direction.)