[MUD-Dev] Languages for MUD drivers

[J C Lawrence]

On Tue, 16 Nov 1999 03:01:55 +0100 
Laurent Bossavit <laurent at netdive.com> wrote:

> Hi all, As my quest for the perfect M* server design continues
> (I've been a deep lurker on the list for over one year, though
> some of you might remember my interest at one time in porting
> LambdaMOO to Java (done, but not the panacea I hoped)) I am more
> and more convinced that the crucial parts are the underlying
> (implementation) and visible (world- building) languages - ideally
> both being the same.

Having recently put this critter into the Library, Momoko comes to
mind.  Rather a cute looking beast.  It is written in Java with a
variety of Python and JPython supports, with the internal
programming language being either (your choice, makes no difference) 
Java or Python.

I've been meaning to look into their data handling model.

> A lot of the issues M* server designers and implementors struggle
> with are in fact active areas of programming language
> research. These are in approximate order of importance (for M*
> writers!)  - distributed processing support (for large worlds) -
> concurrent processing support (for reactive worlds) - object
> orientation (for modular worlds) - object persistence (as in MOO)
> - run-time mutability (aka dynamic recompilation, as in MOO/ColdC)
> - reflective capabilities (so programs can modify themselves) -
> security (to enable in-game access to world code by 'wizards')

Give the man a cigar.  The same topics are regularly featured here.

Have you looked at Arjuna?  A rather interesting system if, now,
less publicised that it was.  I think I still have the
pre-commercial tarballs about somewhere.

> If we assume a language with the above properties, writing a M*
> driver is almost trivial. 

A toy idea of mine has been to hack Python into being a truly
persistent language.  It already is (reasonably) thread safe (single 
lock), and then run that in normal DB style atop a lockless DB using 
something like CoolMUD's RPC model.

> A thin layer of network code will handle client connections; a
> command parser will probably provide the most challenging exercise
> in low-level programming, writing core character/monster/item
> classes would almost belong to the 'world design' category.

And is the greater volume of the work required.  You can write a
server with an embedded language in a few thousand lines of code.
The game world takes several hundred thousand lines with a much
higher density of function points.

> I've recently been looking a dozens of languages old and new to
> see if any fit the bill - I'll mention as a random selection
> Obliq, Phantom, Oz, Erlang... So far only one actively supported
> language comes really close, E (www.erights.org). 

I'd probably head for Python as being "almost there", and actively
enough developed to get there fairly quickly.  The extensions for
distribution and implicit transactions aren't too too foreign to the
language as is (you can probably get away with faking the
disribution piece and letting logical consistency be handled at the
app design level rather than the programming paradigm).

<reader a bit further into E>

Neat stuff.  The following comment is very telling:

  "For 25 years the Actor tradition assumed that in order to do
concurrency control right, we had to give up sequentiality. While
the invention of this deadlock-free alternative may have required
this premise, once invented, E shows it coexists with sequential
programming perfectly well, producing the first Actor language
that's easy to learn."

With the last phrase needs some supporting, the base assertion is
bloody fascinating.

Thanks I wasn't aware of E -- added it to
Top/Programming/Languages/Scripting.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev