Kartik Agaram have you poked around the way fennel-folks tackle this?

I like your way better because it is all lua+love, no emacs 😆

I've played with Fennel very slightly, though I haven't tried to set up any emacs integration.

I have no doubt Emacs is far more powerful in these capabilities. Hopefully my stuff can act as a gateway drug for a few people.

yeah -- my goal here wasn't to push you to emacs (I would never recommend anyone pick it up...as a life long emacs addict), but to flag that folks are doing this sort of interactive dev with love using fennel.

I think the main guy behind fennel even has a package specifically for doing it. Sort of like an embeddable editor.

• git.sr.ht/~technomancy/polywell

Thanks! I don't think I'd ever actually tried this, even though I follow technomancy on Mastodon. People are too retiring about plugging their stuff, compared to me 😆 I'm going to try it out.

Oh, Polywell doesn't even require Emacs.

The original blog post says an error crashes the whole app. And I spot checked a few places in Polywell from my phone and didn't see any error handling. So maybe that's one difference. Both my driver.love and this new approach are robust to errors. (The motivation for this new approach: someone was trying to use driver.love on iPad, where the OS only permits one LÖVE app to run at a time.)

There's also a minor difference in the communication mechanism. Polywell uses a separate thread, but it seems to be just to get non-blocking I/O. driver.love uses a temporary file for the same purpose. Feels like fewer moving parts, but this is subjective.

There's no reason you couldn't read/write the temporary file from Emacs and get all its sweet sweet power. Conversely, there's no reason you couldn't switch Polywell to driver.love's error handling and/or simpler communication mechanism.

Ah never mind, Polywell does use xpcall : git.sr.ht/~technomancy/polywell/tree/main/item/config/console.fnl#L42

In the game of FoC Patreon Tiers, Visual Programming is in the lead. Type System purists, where you at!?

Thanks for another fun episode! Here are my notes.

Alan Kay's vision is focused on communicating by giving other people an executable simulation of your idea, not just figuring things out for yourself. His work on "active essays" is all about embedding simulations within a document for the purpose of improving communication.

With respect to programs that write programs, Andrew Hume supposedly said "Programs that write programs are the happiest programs in the world."

Regarding "The computer is the fake bit and the program is the real part," though I cannot find a primary source, Dijkstra is sometimes quoted as saying "Computer Science is no more about computers than astronomy is about telescopes."

Also, from SICP (mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-7.html), "First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute."

If Dijkstra the Formal AND the freewheeling MIT crowd BOTH agree with you, Jimmy, then you might be onto something.

On the subject of modifying existing programs, one outstanding success story is Emacs. Emacs is really easy to customize in little and big ways because it was designed to be customized, with extensive support for custom key mapping, configuration, and the ability to install hooks before and after almost every important action. The result Is that it takes very little code to insert a little tweak in behavior wherever you want to. This wasn't an inevitable consequence of the language or the development environment, although they were a tremendous help. It came from a steadfast commitment to customizability at every stage of the design and implementation.

It also offers a gentle on-ramp to programming because the user can start with small customizations and gradually ramp up to more intricate ones. There is no point in the journey where you need to stop playing and go learn how to program all at once.

I especially love section "8.3 Blue Sky" in the original Emacs paper.

dspace.mit.edu/handle/1721.1/5736

I think Peter Naur's paper Diminishing Returns of User Programming (1978) is relevant to this whole conversation. As languages become higher and higher level, they tend to either become specialized and limited, or to have an explosion in vocabulary. Some people think that domain-specific languages are a way to escape this trap, but somehow this dichotomy must be addressed if we want to create a form of programming that is easy, high level, and general purpose.