People who like this should consider sponsoring both Borkdude and PEZ on GitHub. They do amazing work for the Clojure ecosystem.

NB: The video has a target audience of people who know Clojure and its strengths. Especially how the REPL is used. I hope HN will see beyond the parens. =) It should make some sense anyway. Especially if you have some Emacs scripting experience, because that is where most of the inspiration to Joyride comes from.

But usually I do get sleep. The question we should ask is if borkdude sleeps? He's doing about 100X as much as I do. Maybe there are hundreds of borkdudes.

- Philip Larkin

- Tony Montana

    (insert (number-to-string (setq counter (+ 1 counter))))

Agreed on both counts.

But I don't think it's possible to get to Emacs' level of extensibility unless you adopt its philosophies - both legal and technical - from the outset.

The reason I say this is that Emacs isn't just extensible in Emacs Lisp, it's very extensively written in Emacs Lisp. More than that, the code behind all of the functions is a keystroke or three away. If I want to know what 'C-x C-s' does, it's possible to say 'C-h k C-x C-s' and see this:

> C-x C-s runs the command save-buffer (found in global-map), which is an interactive compiled Lisp function in ‘files.el’.

There's more documentation besides, and pressing enter on 'files.el' then takes you to the source code for the save file function. This works for native C code too, provided you have the source installed.

This is very much like what you see in a Smalltalk image or a Lisp machine - the system is all 'of a kind', self-documenting, and fundamentally open by nature.

Web Browser JS environments have some of the interactivity here, but they miss out on the self-documenting part, the use of the extension language as an implementation language, and all the cross linking into the source. I'm not faulting them - these are expensive and time-consuming choices to take - and they are often at odds with the goals of writing a useful browser.

In that perspective, the work here is admirable in that it adds Lisp style scripting to VSCode, but it's destined to never get close to the sort of interactive extensibility and exploration you get in Emacs itself. I'm sure it's easy to run into the wall between the extension language and the implementation language itself.

Before this is taken as too critical, note that I don't mean it that way. This is just an observation about two different design choices based on two different sets of constraints that have led to two different outcomes. Note that both of these outcomes are good and useful points in the design space.

Having, draw a rendom number out of a hat, 50% of Emacs extensibility at your REPL is fantastic, and worth pursuing. Joyride can do everything a VS Code extension can do, except the things i mentioned above, and anyone who has used some VS Code extensions knows that that is a lot.

However, the self documenting part described above is not out of reach. Most of the code building up the VS Code API is open source. Same goes for many of the extensions. Looking up and navigating to any of that code is possible. Perhaps a lot of work would need to be put in, but it is possible.

Writing that made me challenge it. What if it is possible? https://github.com/BetterThanTomorrow/joyride/discussions/14

https://gist.github.com/borkdude/08ec3ae2af5963a4a03cd8e0873...

Edit: My usage of Emacs has been reduced to mostly just magit and dired since ~2017, so I didn’t realize Emacs 26 added threads. Is it actually widely adopted? Things I do use these days, like package.el, are clearly still blocking.

https://github.com/babashka/sci