5 ms·

Well, did we? You can still do that! Those environments were extremely primitive and it doesn't take much work to match or vastly exceed their capabilities. Thi

Well, did we? You can still do that! Those environments were extremely primitive and it doesn't take much work to match or vastly exceed their capabilities. This is so much the case we often don't even recognize such environments staring us in the face. Consider another story on the HN front page right now: IntelliJ 2021 is out. Load IntelliJ and you have something that which can be arbitrarily scripted, altered and extended as it runs, and which appears to match/exceed Genera and the other demo'd systems. Here are some features of IntelliJ that are reminiscent of a single-address-space fully reflective operating system: • A multi-language scripting console that lets you access arbitrary parts of the IDE and give it interactive commands, either via its real API or (using reflection) anything else: https://www.jetbrains.com/help/idea/ide-scripting-console.html https://www.jetbrains.com/help/idea/ide-scripting-console.ht... • An interactive debugger that can debug any app, including the IDE itself. Of course it can be risky to use breakpoints as you might suspend the debugger you're using and get stuck, but that's a conceptual issue, not a technical one. • An interactive auto-completing command line like thing for commands, files, symbols, menu items etc. Double-shift opens it for me. • Real-time CPU, memory and task monitors. Try opening the command palette, type CPU and then pick "CPU and memory live charts", or search for "activity monitor" and open it. • A fully virtualized filesystem layer with sophisticated file explorer. You can explore 'into' files at the structural/symbolic level. • Obviously it's the JVM so everything is fully garbage collected. • A whole UI framework that supports both tiling and floating windows. • The ability to load, unload and upgrade apps (plugins) on the fly without restarts. They can alter the behaviour of the environment and other plugins, either via real APIs or by the big hammer of loading a JVM agent on the fly. JVM agents can rewrite code in any arbitrary way and swap it into the app as it's running. And you can program it with Lisp if you really want to, via Clojure. I watched the talk, it was a nice talk, but I couldn't help feeling that the answer to "What have we lost?" is actually - cynically - not much. Those environments had some interesting ideas and the good ones seem to have made it into production, just not via custom hardware and operating systems. Edit: interesting how quick this hit -1. I think a lot of people like the idea of lost treasures in computing. I used to like it too. But I can't identify something these machines or operating systems do that is strictly superior to modern technology or large-scale 'operating environments' like IntelliJ.

thequux 6y ago
IntelliJ idea is, in many ways, more advanced than Genera, yes. I use it every day. But I stand behind my assertion that we've lost something there: Genera had most of the features you listed (even though I didn't have time to show them), and in the case of debugging the debugger, AFAIK, you can't get IntelliJ into a state where the debugger is debugging itself, because in order to attach a debugger to an instance of IDEA, you need to run a second instance. Adding plugins without restarts in IDEA is a feature that's only a couple of months old now, and even then, making your own plugin is a very involved process. You can't just copy a single function into your own code, modify it, load it, and be done. In genera, that would take 1-5 minutes; quick enough that if something bothers you, you don't really need to think about whether it's worth taking the time to fix it. By the time you've done a cost/benefit analysis, you'd have been done with the fix.
- thu2111 6y ago
  I think you're right that the UI will block you from debugging itself, but, this is just a safety check that could be disabled. It might be a fun project to try and turn IntelliJ into a fully Genera-like environment. I think as part of that you'd need to teach the debugger how to attach to itself without risk, probably by defining some notion of a protected system thread and then preventing breakpoints from affecting them. The JVM is certainly capable of doing this, although the debugger UI would have to be extended. I guess Genera either didn't have breakpoints or had some equivalent notion of un-breakable operations. It's true that there's no way to just edit a single function and replace it, at least not out of the box. This is partly conceptual - Symbolics Lisp was pretty much a dynamically typed language if I remember correctly, as are most Lisps, and didn't have any real notion of version control or a compiler checking things for you ahead of time. You wouldn't want to edit only a single function in isolation if editing the internals of IntelliJ because a lot of the value of the tooling is putting the code in context via type checking, static analysis, folding and so on, which requires the rest of the code to be available and ideally visible. Still, there's nothing missing from the core technology. To make things editable like that you could have a plugin that grabs the matching source zip for a selected symbol or bit of UI and opens it in a new project window, configured in such a way that compiling it causes it to be reloaded into the IDE. Either via the plugin reload mechanism or the bigger hammer of something like DCEVM, which lets you arbitrarily redefine classes at runtime even if their field layout changes. It's more of a workflow issue than anything else. The additional overhead is mostly buying you things you'd want anyway, like a notion of sharing and version control for your changes.

thequux 6y ago

IntelliJ idea is, in many ways, more advanced than Genera, yes. I use it every day. But I stand behind my assertion that we've lost something there: Genera had most of the features you listed (even though I didn't have time to show them), and in the case of debugging the debugger, AFAIK, you can't get IntelliJ into a state where the debugger is debugging itself, because in order to attach a debugger to an instance of IDEA, you need to run a second instance. Adding plugins without restarts in IDEA is a feature that's only a couple of months old now, and even then, making your own plugin is a very involved process. You can't just copy a single function into your own code, modify it, load it, and be done. In genera, that would take 1-5 minutes; quick enough that if something bothers you, you don't really need to think about whether it's worth taking the time to fix it. By the time you've done a cost/benefit analysis, you'd have been done with the fix.

thu2111 6y ago
I think you're right that the UI will block you from debugging itself, but, this is just a safety check that could be disabled. It might be a fun project to try and turn IntelliJ into a fully Genera-like environment. I think as part of that you'd need to teach the debugger how to attach to itself without risk, probably by defining some notion of a protected system thread and then preventing breakpoints from affecting them. The JVM is certainly capable of doing this, although the debugger UI would have to be extended. I guess Genera either didn't have breakpoints or had some equivalent notion of un-breakable operations. It's true that there's no way to just edit a single function and replace it, at least not out of the box. This is partly conceptual - Symbolics Lisp was pretty much a dynamically typed language if I remember correctly, as are most Lisps, and didn't have any real notion of version control or a compiler checking things for you ahead of time. You wouldn't want to edit only a single function in isolation if editing the internals of IntelliJ because a lot of the value of the tooling is putting the code in context via type checking, static analysis, folding and so on, which requires the rest of the code to be available and ideally visible. Still, there's nothing missing from the core technology. To make things editable like that you could have a plugin that grabs the matching source zip for a selected symbol or bit of UI and opens it in a new project window, configured in such a way that compiling it causes it to be reloaded into the IDE. Either via the plugin reload mechanism or the bigger hammer of something like DCEVM, which lets you arbitrarily redefine classes at runtime even if their field layout changes. It's more of a workflow issue than anything else. The additional overhead is mostly buying you things you'd want anyway, like a notion of sharing and version control for your changes.