Hey this is unrelated. I have a question about PPLs: have you heard of anyone using them to implement the Chaos Game?

Nah, I haven’t heard of it. I’m curious, though. Bookmarked.

This is great! Elements of Block Protocol and Literate Programming combined together in a new and interesting way.

Literate programming is definitely one source of inspiration! This is a form of "within-document tangling". Next is treating filenames and ID's interchangeably so that files can be included.

There are some interesting graph problems in that.

Oh, and the project lives here on github if anyone is interested in the source. There is quite a lot of it compared to what it does so far...

Beautiful! You built something I dreamed of a few days ago. Loving the natural and terse ... syntax for placing snippets, and the simple piggybacking onto md's image tag. Why is your code in blockquotes though instead of triple-backticks? Very interested to see how you approach file tangling. Filesystem-to-editor unidirectional inclusions will probably be easier than the other way round. Do you think bidirectional editor<>filesystem tangling would be possible at all? Maybe tracking modification timestamps?

and the simple piggybacking onto md's image tag.

There's some level of depth in this one which i'll expand upon. The original inspiration (unspiration) was that GitHub added support for a syntax like this some time ago. This was how the syntax got started.

In fact, one of the goals is to be superficially markdown-compatible. I.e. headings, lists, even "NOTE" blocks should be valid both in this project and on GitHub....

Why is your code in blockquotes though instead of triple-backticks?

...but that's where the superficial compatibility with markdown ends.

This project is a playground for a few ideas i've had. One of them is related fascination over languages that don't have explicit "start" and "end" tags or fences (backticks). Hence, one of my explicit goals was to get to something that won't need me to use closing tags (i'll have to write design goals down some day).

It's a fun challenge! However, like you immediately noticed, using > is janky. The future solution to this is three-fold:

• First, a block can be started by one of many characters. Blocks are generalizations of what markdown calls "lists", "headings" and "blockquotes". That means, lists are blocks (of semantic type LIST , and so on.
• Second, supporting Markdown's "original" syntax of two-space indentation for starting a (code) block, which would make the current example almost "normal".
• Third, i have something i call "sections" that are allowed on the root level. Hopefully i'll get to demo those in a few weeks.

Very interested to see how you approach file tangling. Filesystem-to-editor unidirectional inclusions will probably be easier than the other way round. Do you think bidirectional editor<>filesystem tangling would be possible at all?

I have some initial parts of this in my design, but the devil is in the details. It's one thing to support "a" editor, and another to support "any" editor. What you see on the video is an editor in the browser. I'll focus on that for now, but following filesystem events would be cool.

I've approached the architecture like a build system. There's an internal graph of tasks (think: load, parse, render) that should allow for both tangling (writing out) to filesystem, as well as loading in (weaving).

Loading already works somewhat, but working with graphs is tricky, and we'll see what's possible.

Maybe tracking modification timestamps?

This is definitely one key piece in there. Not sure what else, tracking syscalls?

One more fun thing is how to compose many includes in one place, here's what works already:

Thank you for your thorough reply. Super excited follow your progress on this. Can you say more about why you wish to avoid explicit end markers?

Can you say more about why you wish to avoid explicit end markers

For fun mostly! But also, because I spent some time thinking too deep about what why Python chose to use indentation for scoping. There are some interesting properties, if you do "what python did" but for a markup language.

For example, there can not be "too many right parentheses".

This is useful, if you do collaborative editing. Consider what happens when someone writes <div> in a collaborative html document. All lines after it are potentially affected, until a </div> is added (some time later). So someone editing content at the begining of a document can break a document for someone editing the end. Using a no fences, or "line-based" or "indentation based" language alleviates some of these issues, at least in naive cases.

...But mostly for fun!

That's a very helpful explanation of the why of hest, actually. I think I get it now, in a way that I didn't get it before. You don't want to rewind like scrubbing a video, for example. You want to sort of tilt the world, changing the direction of gravity's pull, and have the river of computation pour back up the hill. Because hell yeah.

Yes. It's not taking you back to an earlier state, it's executing things in reverse. And if you changed the data manually, executing in reverse takes you to a state you hadn't been in before.

Just to double-check — did you listen to episode 40, or 38?

You could do some kinds of logic programming by designing molecules with two different types of binding sites, where each binding site has a graph diagram that represents a logical clause, variables on all binding sites are connected, you throw copies of these molecules into a solution, catalyse a query molecule type to do backward chaining, catalyse a fact molecule type to do forward chaining, catalyse a rule molecule type to do middle-out chaining, and agitate the solution so catalyzed molecules will be attracted to and bind to other molecules with a graph diagram that unifies on the opposite binding type. As you agitate, you get a preview of the new molecules being formed. When you remove or run out of catalyst, any newly formed molecules with empty binding sites dissolve, and the remaining new molecules represent answers to your query. "Stable model constrained answer set chemistry." 😅

Thanks for this episode Ivan Reese .. I recognize the feeling of missing that liveness that you describe (I've very intensively played with ableton in the past and off course I recognize the experience of dealing with css .. which is much different then regular programming. My first paid project was a game actually .. in 1991 .. but in a pretty dead programming environment: 6510 assembler). When I see the dots moving in my own project (code flow canvas) and play around with the timeline slider and make changes I do get a bit of an "it's a live" feeling myself.. but I know it's far from that. I want more of that for sure 😊 . So I keep exploring as well 😄

It was 40! The reversing time thing is just an example of what I feel like I hadn't grokked before.

It loads so fast I had to make it load faster, also the fact it did not work offline was annoying me. I've added the ability to bundle Observable FileAttachments to support images, but this also unblocked me to include static JS libraries, and then eventually supplying Observable's builtins as file attachments, but gzip compressed. So the final result is it expands to 300kb, but all dependancies are gzipped inside the page.. no CDN fetches or DNS stalls => sub 100ms loading time! For comparison the same notebook takes 3 seconds to load on Observable. I think the core tech is done, now I switch to ironing out some remaining warts like some of the cells get unnecessarily reordered.