Geek Stuff
Sep. 27th, 2004 11:10 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
noahgibbsPeriodically I bug some of you about one damn thing or another related to MUDs - multiplayer text games.
One of the reasons I'm so attached to that stuff is that DGD, the server I use for my MUD stuff, is an absolutely crazily cool little tool. It does some frightening things, and I don't know of any other language that does them. This is one reason that callout to other languages from DGD can really suck :-)
Anyway, a lot of those features are geared toward a persistent server - a server that runs as though it never went down. If anybody with a strong technical bent and (for preference) no real experience with DGD wants to look over an in-depth explanation of what that means, and how it impacts your programming model, I've written a summary. It also happens to read like a tour of DGD's weird and unique features, though it actually skips the ones that sold me on DGD originally :-)
That's okay. There's plenty of time to write a summary on those, too. I've just depressed myself by doing line counts and character counts, and it turns out I've typed about a megabyte of stuff for this site, over the years. Over 25,000 lines. That's not counting the binaries, the external stuff I've downloaded and placed, the cut-and-paste mailing list messages...
That's, like... That's a novel. It's not really even a small novel.
One of the reasons I'm so attached to that stuff is that DGD, the server I use for my MUD stuff, is an absolutely crazily cool little tool. It does some frightening things, and I don't know of any other language that does them. This is one reason that callout to other languages from DGD can really suck :-)
Anyway, a lot of those features are geared toward a persistent server - a server that runs as though it never went down. If anybody with a strong technical bent and (for preference) no real experience with DGD wants to look over an in-depth explanation of what that means, and how it impacts your programming model, I've written a summary. It also happens to read like a tour of DGD's weird and unique features, though it actually skips the ones that sold me on DGD originally :-)
That's okay. There's plenty of time to write a summary on those, too. I've just depressed myself by doing line counts and character counts, and it turns out I've typed about a megabyte of stuff for this site, over the years. Over 25,000 lines. That's not counting the binaries, the external stuff I've downloaded and placed, the cut-and-paste mailing list messages...
That's, like... That's a novel. It's not really even a small novel.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Contrasting to MOO
Date: 2004-09-29 12:23 am (UTC)From the user point of view, a MOO is completely dynamic: it's got object-based inheritance (similar to SELF or NewtonScript, or probably some others I'm not familiar with -- CLOS?), and object methods can be edited by users. (The parser system automatically ties object methods and verbs together, so a new method pretty much becomes something that can be done to an object.)
As I recall, LambdaMOO was memory based at the time I was looking at it -- snapshots could be taken for back-up (and pruned, for distribution as pristine images for starting up a new installation), and restored without any perceptible change. (Naturally external things like IP connections needed to be managed specially.) But there wasn't explicit object saving/loading, or the explicit concept of persistence: object data and methods always persisted in-memory until changed, and memory was/is eternal.
From the back-end, I think there were efficiency hacks (compiled methods, maybe special fields for storing particularly important object fields), but these didn't need to be visible to the user.
All of the programming was in the high-level language concepts of the MOO language -- modern interpreted language concepts (strings, arrays, etc.) Never anything like int pointers, and there was never any reason I found to worry about the underlying object-storage format.
So... for me, the description of peristance in DGD doesn't mean much to me, simply because I'm not used to an environment that doesn't have those characteristics.
Re: Contrasting to MOO
Date: 2004-09-29 10:30 am (UTC)You can actually run a LambdaMOO emulator on top of DGD called LPMOO - it has an interpreter for LambdaMOO scripts. In that case, the only difference between your experience above and the way it would work is that it's turtles all the way down, as it were. The MUD keeps a memory snapshot of the MOO code, DGD keeps a memory snapshot of your LPC code, and if DGD gets upgraded (which it frequently does), your LPC memory snapshot remains forward-compatible.
But bearing in mind that DGD can be used for a wide variety of non-MUD projects, a better example might be an HTTPD that does the same thing, or a Perl script -- imagine you could upgrade Perl underneath your Perl script while the script was still running, and without even bothering to disconnect the current people running the script, plus you could add features to the script and change object behavior in the same way.
That's not a perfect example. You actually *do* have to disconnect the users to upgrade the DGD server itself, so you'd need some kind of process-to-process failover to manage that if you wanted it *really* seamless. Turns out that that would be easy, come to think of it, but it would still require a bit of extra code and resources.