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

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.

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!

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 🙂