Hmm. This post was meant for a different Slack. I'll leave it hear in case anyone here is playing with LLMs. Sorry for the cross-post.

I love the way it handles markdown presentation and editing — full of good ideas! (But I don’t use it.)

Haven't seen this before, but it does look quite nice, may give it a try! 😄

Features this lovely Borges-esq quote,

Imagine a novel, which is imbedded in a longer novel, which itself is imbedded in an even longer novel, and so on ad infinitum. Within each novel, the characters can debate the literary merits of any of the sub-novels. But, by analogy with classes of machines that can’t analyze themselves, the characters can never critique the novel that they themselves are in. (This, I think, jibes with our ordinary experience of novels.) To fully understand some reality, we need to go outside of that reality. This is the essence of Kleene’s hierarchy: that to solve the Halting Problem for some class of machines, we need a yet more powerful class of machines.

I haven't — queued! Just gave it a quick skim, and was pleased to see Rudy Rucker's Infinity and the Mind get a reference. RIYL.

I read it a while back. I generally enjoy Scott Aaronson. If I hear crazy news in computability theory or quantum computing I head for his blog to see his take. :)

When people ask me what the downside of something like CellPond 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): publish.obsidian.md/programmingsimplicity/2023-08-12-Summary+of+Paper+Live%2C+Rich+and+Composable

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.