Both the Java and .NET ecosystems are monumental (in every sense of the word) engineering accomplishments, but they don't strike me as very similar to the ultra-dynamic, introspective Lisp Machine experience. Can you elaborate on that a little bit?

FWIW, the browser (though still far off) feels closer to me, with the ability to instantly pop open a DevTools console and inspect the state of everything, as does Apple's Cocoa-based stuff from my limited exposure to it, maybe not surprising given its Smalltalk heritage.

You have to think about the whole ecosystem and not only the VM.

Dynamic nature of the runtime, being able to plug agents, changing code dynamically, the IDE experience inherited from Smalltalk vendors that jumped into Java, VisualVM and JFR, ETW, runtime APIs to the JITs, self hosted implementations, nowadays out of fashion, sending bytecodes for RPCs and network agents (RMI, .NET Remoting, Jini), are some of the reasons.

Exactly... the JVM is incredibly dynamic. It's gone totally out of fashion because of security and complexity, but I used to enjoy using OSGi to load just about any Java library into the runtime by typing its Maven coordinates, then immediately start using the library from a shell... and then just remove that lib if I didn't "like it" and it would be gone as if it never existed... I don't think a lot of people realize you can quite easily do that kind of thing on the JVM.

Yeah, it is no accident that a JIT designed originally for Strongtalk ended up becoming the first JIT for Java.

And .NET by being "Java 2.0" after the J++ lawsuit, inherited most of the same dynamism, alongside the ability to support VB capabilities, which by VB 6 were also quite nice.

Part of the idea of WASM components is to support these same tricks with a more modern, better performing standard platform.

That is the sales pitch, the reality is that 10 years later it is still catching up with features offered by other bytecode formats explored since UNCOL came to be in 1958.

The feature and bug of the OSGI experience is its rather coarse granularity. It’s finer grained than, say, a WAR, but obviously much different than something akin to the Smalltalk or, to a lesser extent, Common Lisp.

That said, make no mistake, an OSGI module can easily fall into that sweet spot of compiling and reloading fast enough to fall within the cognitive loop of effectively being “instant”.

And if you organize your code well, other parts of the overall app are (mostly) unaware something has changed. Java can be quite dynamic but has not formalized things like dynamic class change lifecycle. OSGI does expose that, and lets the rest of the code tap into that so it can handle change more robustly.

Another alternative is to use JVM plugins like JRebel.