[vworld-tech] Modern MUD server design
hook_l at pyrogon.com
Thu Feb 19 21:48:06 PST 2004
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
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" )
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
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
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
> 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.
More information about the vworld-tech