For one, I think MOO is kind of shite in lots of ways. But I and others spent lots of time 20+ years ago building alternatives and nobody used them. There's intrinsic value to just picking up and then improving on something that has established history. It gathers an audience of users, has name recognition, and most importantly keeps you responsible from an engineering dev POV because you are forced to focus on delivering a thing that works and you have a way to prove it. As Linux has shown, incremental improvement on a somewhat flawed but relatively popular and known foundation has value. mooR cakes over a lot of the ugly parts of MOO and honestly, I'm pretty proud of it.
Secondly, existing "mainstream" languages are not appropriate, mostly. None of them or their runtimes are really based on a properly sandboxed persistent model. I poked at WASM, and I could write a screed about that, but wrong system. MOO (and successors to it) were built with the idea of lots of people jamming on one shared world, and it shows.
Finally, I have all sorts of ideas on what I think is "better" than MOO, and did eventually open the floodgate this spring and start building out the "dream system" here: https://github.com/timbran-project/mica -- but as you can see from relative star count of one vs the other.. my first point has relvance.
There should be an explanation in the book on how loading works. If not, I'll need to clarify. Documentation writing sucks. But the TLDR is that one of the arguments you pass to the system at start is basically a source directory of ("objdef") human readable / editable source files, and that gets compiled into a persistent binary database. Once that's done, restarts load directly from that DB/image, not source. (But the system can periodically export or "dump" objdef files as well).
Note this is a bit different from classic LambdaMOO, which had no such process. It had a primitive text database that was not human editable really, and you started from what people passed around of those.
Hope that helps. Come by the discord if you have questions: https://discord.com/invite/Ec94y5983z
Also I just finally put up a new blog post on dev status https://timbran.org/catching-up-with-moor.html
EDIT: I've done some book edits and added a chapter here which I hope helps: https://timbran.org/book/2.0-dev/html/the-system/bootstrappi...
Right. I kind of forgot that MUDs are supposed to be social. Seeing as the popularity of MUDs plummeted, I also changed my goals over time: I want to build a persistent, text-based (but with rich formatting support, including eventually GUI widgets) live programmable environment with network transparency and multiple concurrent sessions allowed. Since it's personal/local space first, and only allows others to "visit" (and even that is mostly for my own remote sessions), I don't need many users initially. If I was trying to build something that emphasizes the multi-user aspect, the choice of continuing one of the historical lineages would be much harder to avoid.
> Secondly, existing "mainstream" languages are not appropriate, mostly. None of them or their runtimes are really based on a properly sandboxed persistent model.
You're right. And even if you broaden the search so much that "mainstream" is barely visible from the cut-off point, you're left with basically just Smalltalk. My current attempt is based on GToolkit distribution of Pharo Smalltalk - it does check some boxes, but it's class-based (not a big problem given the dynamism) and VERY single-user by design (quite a big problem, and thinking about eventual security/permissions/capabilities handling gives me a headache). Still, from all the prototypes I made over the years, this attempt went the farthest; I think I'll stick with it for a while longer.
> Finally, I have all sorts of ideas on what I think is "better" than MOO
Thank you, I will definitely check it out :)
> But the TLDR is that one of the arguments you pass to the system at start is basically a source directory of ("objdef") human readable / editable source files, and that gets compiled into a persistent binary database.
Thanks. That's exactly how a Smalltalk image is built, too, at least with the tooling I'm using (GT). You start an image, point it to a set of Git repos with Smalltalk code, which is then loaded into the image, classes are created, and methods get compiled. You then dump the new image. When you start it the next time, it already contains all the code, and you can change it inside the image at runtime, as much as you want. At some point, you export the changed code back to Git repos, and regenerate the image. Since the image contains all the live objects as well, you can close it, and all the state is restored when you reopen it.
Thanks for the Discord invite, I just joined. I'll go over the book and try to run mooR and mica first, and will reach out for help if needed.
For mica specifically: I'm not 100% sure, but I seem to remember you describing the idea behind it much earlier (here on HN) than this spring. I think it was in comments under a Python-Prolog bridge or something like that. Good to see you had the time and motivation to implement it :) I'll definitely give it a read!