[MUD-Dev] Languages for MUD drivers

[Cynbe ru Taren]

On Tue, 16 Nov 1999 "Laurent Bossavit" <laurent at netdive.com> wrote:


| I am more and more convinced that the 
| crucial parts are the underlying (implementation) and visible (world-
| building) languages - ideally both being the same.
|
| [...]
|
| 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')

That's pretty close to the set of design goals I've used in the
Muq design and implementation.



Personally, I would add to the list:

  - multi-user               (This is -not- the same as "security" above)
  - disk-based for large dbs (This is -not- the same as "persistence" above)



I would also suggest that "object persistence (as in MOO)" might
understate the design issues: "distributed", "persistence" and
"multi-user" all introduce new issues dealt with glancingly or not at
all by the mainstream OOP literature, such as:

 *  What happens to existing instances of a class when it is redefined?
    (CLOS addresses this, Smalltalk, C++ &tc do not.)

 *  When is an object O to be considered an instance of a class C?
    (Nontrivial in the distributed context if O and C can be
    on separate servers, and perhaps with multiple class instances 
    purporting to define C present on multiple servers and likely
    evolving independently.)

 *  Who is allowed to update, subclass and instantiate a given
    class?  A bad answer here can saddle the system with intractable
    security and/or maintainability answers.



| If we assume a language with the above properties

I think "language" is the wrong concept here.  The above constraints
all really apply to the underlying virtual machine and runtimes, and
have virtually nothing to do with surface syntax.

Reflect that the Java virtual machine, just like the Intel x86
architecture, can be programmed in any one of a number of languages,
including Java and Scheme.  The particular syntax chosen will not
affect any of the above properties, really, modulo perhaps oddities
in the particular OOP model assumed by the language spec.

The conspicuous failure of half a centuries' worth of religious
wars over language syntax to produce a concensus One True Faith
suggests that as a practical matter, a system aspiring to attract
and retain a diverse virtual community will probably need to
be theologically fairly neutral and support most of the major
syntactic faiths.

Muq, if it matters, has a well-developed Forthish syntax, a rapidly
evolving C/Perlish syntax, and a half-finished Lispish syntax, with
more likely to appear shortly.  Adding C-ish syntax support added
maybe 1% to total system lines-of-code count, which I think is a
pretty fair measure of how significant language syntax issues are to
overall system design and implementation in virtual world servers of
this class.



| The underlying (implementation) and visible (world-
| building) languages - ideally both being the same.

I do not find this obvious.  Unless I am clearly the dumbest
person on the list, it might be worth expanding on this.

Typically different design requirements call for different
engineering solutions, and it would seem that the above
two problems have very different design requirements.

Picking a single wide-spectrum language is a a legitimate design
choice, but "the jack of all trades is master of none," and it is not
obvious that one jack is necessary better than than two masters.
IMHO. :)



| Phantom, Oz, Erlang... So far only one actively supported language 
| comes really close, E (www.erights.org). It's unfortunately not quite 
| finished yet - the language spec itself is still evolving and 
| persistence is not implemented

They've claimed to be inspired in part by Muq, at least on occasion. :)

E is an interesting effort, certainly one of the few real attempts
to innovate of late.  I'm a bit skeptical of how well some of their
design ideas will fare in the real world, but that's pretty normal
with real innovation -- time will tell!

Given the amount of effort you've put into evaluation, it would be
a service to the list if you'd sketch concisely the weaknesses and
strengths of the systems you've looked at, and why E tops your
evaluation.  Assembling something in Java based on various
off-the-shelf subsystems (Voyager &tc) is another alternative
you presumably evaluated?

  Cynbe




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