[MUD-Dev] Languages for MUD drivers
Petri Virkkula
pvirkkul at iki.fi
Thu Nov 18 09:20:30 CET 1999
>>>>> "Laurent" == Laurent Bossavit <laurent at netdive.com> writes:
Laurent> A lot of the issues M* server designers and implementors struggle
Laurent> with are in fact active areas of programming language research. These
Laurent> are in approximate order of importance (for M* writers!)
Laurent> - distributed processing support (for large worlds)
Laurent> - concurrent processing support (for reactive worlds)
Laurent> - object orientation (for modular worlds)
Laurent> - object persistence (as in MOO)
Laurent> - run-time mutability (aka dynamic recompilation, as in MOO/ColdC)
Laurent> - reflective capabilities (so programs can modify themselves)
Laurent> - security (to enable in-game access to world code by 'wizards')
To me the MUD building language/server design priorities are
the following:
1) easy language for area builders (this means that there are
no threads, mutexes, etc. in the language
2) stability
3) object oriented
4) security
5) distributed processing for performance
I think Java is bad in respect my criterias. LPC is fine, but
current dirvers do not support distributed processing. Thus
my "dream" driver uses LPC and uses multiple CPUs/machines for
LPC bytecode execution, shares all objects between the
multiple interpreter threads/processes AND hides from area
builders the fact that the driver is distributed.
IMHO synchronization of threads or multiple processes is too
difficult task to give access such primitives to area
builders. The programming environment (the driver) must hide
that kind of issues from area builders, and perhaps even from
mudlib coders.
Petri
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list