The Lisp Machine experience has obvious drawbacks, but there are things that are simply not there on modern platforms (with some exceptions, like a Smalltalk on

The Lisp Machine experience has obvious drawbacks, but there are things that are simply not there on modern platforms (with some exceptions, like a Smalltalk on the metal). Its OS is completely written in a high-level language, it uses a high-level OOP model (for example based on the Flavors / CLOS object systems) and running inside one memory pool. Receiving an TCP packet is a OOP method, just like sending a mail is an OOP message. In the development environment both are fully visible, on the fly changeable, ... If I'm debugging an NFS connection, I could change a UDP method on the fly and it will be immediately active system wide - without any 'hotloading' limitations. You can mostly edit/change everything in the OS and applications without boundaries. That offers countless ways to kill the system, but it means that the TCP implementation is open in the same way like an application is - it can always be used without much performance loss in a full debug mode, where things can be inspected, modified, replaced, edited, ... This is not hotloading of a component, it is a completely open architecture an all levels - from a mailer UI, over the SMTP implementation, the networking stack, down to the network interface. There is a single high-level stack and everything on the stack is accessible/inspectable. One is bringing the thing into a debug mode or deploying it in a debug mode, it can always run fully inspectable and changeable. As mentioned the drawback is that this makes it also fragile when there are very little protections. Make a wrong change to the UDP receive method and the running OS then won't receive any UDP packages...