alt Hacker NewsVery cool! Why reimplement the "moo code", though? Is it "just" for backward compatibility, or did you determine that none of the existing languages can be easily modified to live in a MOO environment?
I started playing on an LP MUD in the late '90s. Over the past 20 years, I tried a few times to implement a similar environment, only with everyone being a "wizard". LPC was also a prototype-based OO language with multiple inheritance, and it supported live development, with code for objects stored in files and dynamically reloadable. I would always hit some kind of blocker, no matter the language I chose for the implementation. It looks like MOOs did (and do) what I wanted, but I just wasn't aware of their existence. :( Maybe if I used MOOs as a model, I'd get better results... but I'm not sure if I want to go all in on DB. I tried looking up how the code is loaded into the DB in the book (https://timbran.org/book), but couldn't find it. Is there an explanation somewhere of how MOOs are bootstrapped from sources, how you can maintain sources in files on disk, and how new definitions are pulled into the DB at runtime?
There's all sorts of reasons, not sure what level of detail you want me to get into. I've got about 30 years of thoughts on this.
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...