[DGD]Hello, think you could answer a few questiosn for me? :)

[John West McKenna]

>    Now for my main question..  What are the main advantages and 
>disadvantages of the MudOS vs. DGD drivers?

The biased answer: DGD is infinitely superior in every way :-)

It's a personal preference thing, I think.  They're both quite capable of
running MUDs.  MudOS does a lot more work in the driver, where DGD leaves
it all for you.  LPC isn't the fastest language in the world, so doing more
work in the driver might be a good idea.  Of course, DGD's precompiling
(compiling LPC to C and linking it into the driver) does very good things
to performance.  Has anyone done any performance comparisions?

The use of 'nil' instead of zero for not-an-object or not-a-string etc
makes a bigger difference than you'd think.

I'm also in love with the object upgrading: unless MudOS has picked up some
new features since I last played with it, you have the destruct-update-
clone cyle every time you make a change to anything.  If you've changed
something fundamental like the user object, you might as well just take the
whole MUD down.  DGD can replace the code of existing (and running) objects
on the fly.  I've written myself a handy little "upgrade" command that
looks for modified files, and automagically recompiles everything that
depends on them.  I find it painful to go back to MudOS development.

Personal preference again: DGD has far fewer built-in functions, and the
ones that are there are very simple.  This means that anything tricky is
done in LPC, and you don't have to go reading driver source to find out
what it does (who trusts documentation?).  More importantly, you can change
it.

DGD doesn't have closures or lambdas or anything like that.  I don't miss
them - I never used them on MudOS (because I'd never found any decent
documentation, or had someone tell me what they're actually for).

I'm not all that keen on DGD's method for adding extension packages.
Patching the driver source just doesn't feel right.  MudOS's "stick the
file in the directory and it will happen" is nice.

DGD doesn't have snoop() or shadow().  As far as I can see, these are
nothing but security holes.  Does anyone know what they're actually good
for?  What possessed whoever was responsible to include them in the first
place?

There's more, but I'm a bit hazy on the details.  DGD supports saving the
entire MUD state to a file, so you can restart as if nothing had happened.
I've never used this.  It also has compile-time and run-time type checking,
which makes debugging that little bit less unpleasant.


List config page:  http://list.imaginary.com/mailman/listinfo/dgd