[vworld-tech] Modern MUD server design

[Brian Hook]

On Thu, 19 Feb 2004 20:26:31 -0800, Lee Faris wrote:

> Since catching errors at compile time is preferable to runtime, why
> are the main languages mentioned for server development all so
> weakly typed?

It's a trade off.  The more static a language, the longer the turn 
around times.  A very dynamic language can often be loaded 
interactively and executed without anyone noticing.

At the one extreme you have a compiled language like C or C++.  
Discounting DLLs/shared objects, if you make a change in code you stop 
the process, compile, link and restart.  All existing state is lost.  
With a dll or so, you can sort of try to avoid this, but the 
constraints are so major that in all likelihood it's not going to 
happen (i.e. you have to stop all use of any data/functions in the 
DLL, unload the existing one, load the new one, rebind all pointers, 
and pray that existing data is in the same exact format that the new 
routines need).

At the other extreme is a language like Lua, where you can reload 
pretty much anything on the fly.  This is immensely powerful, and only 
achievable because of just how dynamic the language is.  The downside 
-- and I'm speaking from personal experience -- is that the sheer 
number of run-time errors you can encounter is mind boggling.  Simple 
typos can crash things, and if you're doing anything even close to 
being large or that needs substantial uptime, you MUST use a coverage 
analyzer to make sure that no nooks and crannies are going to vomit on 
you.  Proper unit testing helps, but that can be problematic at times.

Common places where a dynamic language might have a hidden crash bug 
is error code.  Maybe you write an error handling block just like you 
always do, since hey, we're all good coders, right?

if some_action() == false then -- this should never happen!!!
   report_errror( "some_action failed" )
   return false
end

Your code handles "some_action()" return false gracefully, 
except...oh, gee, report_error() has one too many 'r's in it!  So when 
that situation DOES happen and you didn't manage to test the error 
handler, kaboom, some message like "attempted to execute nil 
function", and rarely will this get handled nicely.

> small amount of code.  But is it still appropriate to code a large
> piece of software that needs to be highly stable in the same
> language?

Probably not.  I'm still thinking heavily on this.  There are some 
decent intermediate languages such as Pike that are probably good 
compromise solutions, depending on just how important it is to you to 
dynamically reload code on the fly.  

The other option is to go the opposite extreme, make everything data 
and write all your logic code in a compiled language.  That's probably 
a lot more stable, but unfortunately a lot more boring when you're 
trying to write a bunch of custom procedural content.

> And thinking further (bear with me), what is specifically about C++
> that is undesirable?  Can we simply hook up a garbage collector to
> a mud server and be able to develop just as 'fast' as with Python
> (taking into consideration the debugging)?

To answer #1: I don't even have close to enough time for that.  If you 
want a good discussion, read the book "Objects Unencapsulated" by 
Joyner.

You could make the argument that C++ along with a bunch of libs like 
Boost and STL and Boehm's collector might be almost as good as Python, 
but I think you'd be wrong. =)

> Or if that still isn't
> a good solution because of the lack of libraries then why aren't we
> all using ML?  

That's a good question.  I think OCaml would be an interesting 
language to develop a MUD in it, however for some reason functional 
languages aren't that popular with MUD developers (or programmers in 
general).

> using a strongly typed 'scripting' language (does it cease to be a
> scripting language if it's stongly typed..)?

There's a broad spectrum of dynamic vs. static.  My favorite middle 
ground is probably Obj-C, since it's "both".  Unfortunately there's no 
way (I'm aware of) to unload a bundle once it's loaded, so while you 
can load new code dynamically, replacing old code is a bit tougher.

Pike is another interesting candidate, especially considering its 
roots.  It's fast, easy to use for C programmers, has lots of 
packages, etc.  Unfortunately it lacks what I consider adequate 
documentation, and my understanding (without actually bothering the 
Pike mailing list) is that unloading code and/or replacing live code 
is a non-trivial operation.

If dynamically replacing code wasn't so important to me, I'd probably 
be using Obj-C or Pike.

Brian