Ivan Reese 2024-10-03 04:10:32
This is fascinating. I've heard of boxer so many times, but never actually seen it before. It's funny to me that they bumped up against many of the same issues / questions we're grappling with in my current Ink & Switch project:
- When duplicating canvas objects that have behaviour, should those duplicates be a deep copy with no shared internals, or should there be some amount of sharing? How do you approach masters/instances? How do the answers change as a result of this taking place in a spatial environment? How do these answers relate to scoping?
- What about names? Where do names live? Why do you give things a name? How do you refer to things that don't have a name?
- How do you connect things together? How do you multiplex / split? How and when do you see the connections?
- Where do values live? If you're going to execute some smaller part of a larger program, how do you feed it values? When do you see those values?
- How do components nest? How do you expand / contract components? How does information flow across component boundaries?
- What interface elements need to be big because they need to be easy to see, and which ones need to be big so you can touch them, and when are these in tension?
etc etc.
These are all common questions when designing a visual programming system, naturally. But what's funny to me is just how damn similar Boxer looks to some of the hacky / placeholder prototype work we're doing right now, and the small handful of differences. (Wish I could link to it.)
