This was posted here back in March but it didn't g...
# linking-together
This was posted here back in March but it didn't get much discussion (at least, that's what the archive says), so I'm reposting:
When people ask me what the downside of something like


is, I clumsily try to explain that it has no 'reflection', you can't 'manipulate' the rules, move them around, or get them to work together with other programs (other non-CellPond programs, or even other CellPond programs). To improve on CellPond, you'd want to make it more of a 'hybrid' with other stuff. It's not exactly the same, but I think this paper's concept of 'composability' touches on some of that! I think that combining live+rich editors together often has the 'lego brick problem'. Combining them together often feels like attaching lego bricks. As in - there are predefined places (studs) where you can place them. You're quite restricted with what can go where. It feels plastic, and hard. I use Davinci Resolve's Fusion quite a lot, and it certainly feels like that to me (see attached image). Textual code doesn't feel plastic. It feels like 'playdough'. You can mold different parts together, so that they become interlaced. There's a lot more freedom. I think a great example for this is JSX. You can compose HTML and Javascript together in any sort of way you want. It doesn't feel restricted, and you aren't stuck with the hard plastic borders caused by keeping them in different files. That being said, the 'plastic-ness' of live editors is often a feature. eg: Scratch feels restrictive because it wants to stop you from making mistakes. This is great! But how can we do that while maintain some more 'playdoughyness'? I've spoken a bit with Elliot Evans about this, as I think that his

ideas about carets

tackle this problem really well!! (for Polytope) I'm also interested in Hest because of its focus on 'continuous-ness' of data. Sounds less rigid to me. And I'm currently working on a weird thing called Arroost, which aims to be more reflective and intra-composable. Its output is 'more of itself', so it allows a bit more of that. I wouldn't say it's composable, but it's an experimental step towards it. Anyway, really useful paper! It's given me more of the language and context for exploring this sort of thing!
Kagi Universal Summarizer says: ... The document discusses qualities that are important for programming beyond static text. It identifies three main qualities - liveness, richness, and composability. ... This allows domain-specific interactive programming tools to be integrated into general-purpose environments with full liveness. The document argues this can unlock new value for live and rich tools and programming research by enabling composition. It lays out a vision for further exploring the design space at the intersection of liveness, richness, and composability. ... full summary (5 paragraphs):
@Lu Wilson I’m really glad to hear that the paper’s been helpful to you! I agree with your articulation of the ‘lego brick problem’. I have a prototype approach to composing live & rich tools* and I occasionally feel that it suffers from this problem – that the layers of abstraction around components are overly stiff and don’t afford composition as natural and combinatorially rich as I’d hope. But then I remember that the status quo is “no composition at all,” so, y’know, baby steps. * forthcoming at UIST; I’ll share some preprint stuff soon!
Not sure how relevant this is (or how legible it is without context), but “clunky modules” always reminds me of this bit from Timeless Way of Building where Alexander writes about design via a process of holistic differentiation, vs design via combining prefabricated parts.
That feels very relevant! Specifically the "molding" of things to the shape of their surroundings. I should explore this more, thanks for sharing! You're right about something being better than nothing!
As you might guess from my recent submission, I've often used composability in the form of 'escape hatch' as a crutch for things I can't figure out. eg: "I don't know how to allow the user to do X in SpaceTode, so I'll just let them embed JavaScript instead" (similar to how SPLAT allows you to embed Ulam). But this doesn't feel like a satisfying form of composability. It's like a lego brick. Sure, there are lots of different studs that you can attach to, but they're still studs! You can't mold or interlace. So CellPond was my attempt at avoiding that. What would happen if we don't rely on escape? Would it be good/bad/ugly? Answer: yes, those three Now that it's figured out, I want to ask: How could we reintroduce composability? What would it look like? Is it possible at all? Anyway, those are my current thoughts, I've got a lot of things to explore now. Thanks for your helpful feedback by the way! It's the most useful I've ever had!
Thanks for sharing @Lu Wilson! I read this once before and have now read it twice 🙂 The part on Observable resonates with me in relation to my work on Polytope. I like Observable and have used it to make editors, but really find myself wishing that I could use the editors I make in Observable as a part of my code (attached diagram shows the separation between the "code" part of Observable and the "value" part). I really want to get Polytope to a place where it is great for creating and editing editors. I am working on automatic Caret Navigation so that it is easy to create editors that have familiar controls that compose with the controls of any and all other editors you're using. I'm hoping that there will be a bit of a snowball effect once Polytope is a good platform for composable and rich editors where there will be some editors that make it easy to make editors that are good for making other editors that are good for making other editors that are good for making other editors and so on!
re: @Lu Wilson's second comment: I think banning escape hatches could be a good methodology for build a self-sufficient system? If you have to build everything using the building blocks in your system you learn a lot more about how that system expresses stuff and what it can express. I don't have examples or references, but I think its a pattern in programming language design to have a "core" language that is easy(er) to reason about and that you know can express everything in, and then have a "wrapper" language that makes the core language more expressive. Then if you put an escape hatch in the wrapper language, you don't lose the ability to reason about the core of the language.
I want to talk about liveness too but I already wrote a lot so I'll leave it there for now 🙂
I'd be keen to hear :) There's always #thinking-together as well if you have a separate point!